| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Revert "Revert "[mlir][linalg] Replace "string" iterator_types attr with enums in LinalgInterface."" With python code fixed. This reverts commit 41280908e43d47903960c66237ab49caa5641b4d. | 3 年前 | |
[mlir] Make ElementsAttr inherit from TypedAttr This allows implicit conversion from ElementsAttr to TypedAttr, but required renaming the ElementsAttr::getType() interface method to getShapedType. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D148492 | 3 年前 | |
[mlir] Update method cast calls to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: * https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" * Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This follows a previous patch that updated calls op.cast<T>()-> cast<T>(op). However some cases could not handle an unprefixed cast call due to occurrences of variables named cast, or occurring inside of class definitions which would resolve to the method. All C++ files that did not work automatically with cast<T>() are updated here to llvm::cast and similar with the intention that they can be easily updated after the methods are removed through a find-replace. See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check for the clang-tidy check that is used and then update printed occurrences of the function to include llvm:: before. One can then run the following: ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -export-fixes /tmp/cast/casts.yaml mlir/*\ -header-filter=mlir/ -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D150348 | 3 年前 | |
Revert "Revert "[mlir][linalg] Replace "string" iterator_types attr with enums in LinalgInterface."" With python code fixed. This reverts commit 41280908e43d47903960c66237ab49caa5641b4d. | 3 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
Add an operator == and != to properties, use it in DuplicateFunctionElimination Differential Revision: https://reviews.llvm.org/D150596 | 3 年前 | |
Introduce MLIR Op Properties This new features enabled to dedicate custom storage inline within operations. This storage can be used as an alternative to attributes to store data that is specific to an operation. Attribute can also be stored inside the properties storage if desired, but any kind of data can be present as well. This offers a way to store and mutate data without uniquing in the Context like Attribute. See the OpPropertiesTest.cpp for an example where a struct with a std::vector<> is attached to an operation and mutated in-place: struct TestProperties { int a = -1; float b = -1.; std::vector<int64_t> array = {-33}; }; More complex scheme (including reference-counting) are also possible. The only constraint to enable storing a C++ object as "properties" on an operation is to implement three functions: - convert from the candidate object to an Attribute - convert from the Attribute to the candidate object - hash the object Optional the parsing and printing can also be customized with 2 extra functions. A new options is introduced to ODS to allow dialects to specify: let usePropertiesForAttributes = 1; When set to true, the inherent attributes for all the ops in this dialect will be using properties instead of being stored alongside discardable attributes. The TestDialect showcases this feature. Another change is that we introduce new APIs on the Operation class to access separately the inherent attributes from the discardable ones. We envision deprecating and removing the getAttr(), getAttrsDictionary(), and other similar method which don't make the distinction explicit, leading to an entirely separate namespace for discardable attributes. Recommit d572cd1b067f after fixing python bindings build. Differential Revision: https://reviews.llvm.org/D141742 | 3 年前 | |
Revert "Revert "[mlir][linalg] Replace "string" iterator_types attr with enums in LinalgInterface."" With python code fixed. This reverts commit 41280908e43d47903960c66237ab49caa5641b4d. | 3 年前 | |
[mlir] Introduce support for parametric side-effects The side effect infrastructure is based on the Effect and Resource class templates, instances of instantiations of which are constructed as thread-local singletons. With this scheme, it is impossible to further parameterize either of those, or the EffectInstance class that contains pointers to an Effect and Resource instances. Such a parameterization is necessary to express more detailed side effects, e.g. those of a loop or a function call with affine operations inside where it is possible to precisely specify the slices of accessed buffers. Include an additional Attribute to EffectInstance class for further parameterization. This allows to leverage the dialect-specific registration and uniquing capabilities of the attribute infrastructure without requiring Effect or Resource instantiations to be attached to a dialect themselves. Split out the generic part of the side effect Tablegen classes into a separate file to avoid generating built-in MemoryEffect interfaces when processing any .td file that includes SideEffectInterfaceBase.td. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D91493 | 5 年前 | |
[mlir] Introduce support for parametric side-effects The side effect infrastructure is based on the Effect and Resource class templates, instances of instantiations of which are constructed as thread-local singletons. With this scheme, it is impossible to further parameterize either of those, or the EffectInstance class that contains pointers to an Effect and Resource instances. Such a parameterization is necessary to express more detailed side effects, e.g. those of a loop or a function call with affine operations inside where it is possible to precisely specify the slices of accessed buffers. Include an additional Attribute to EffectInstance class for further parameterization. This allows to leverage the dialect-specific registration and uniquing capabilities of the attribute infrastructure without requiring Effect or Resource instantiations to be attached to a dialect themselves. Split out the generic part of the side effect Tablegen classes into a separate file to avoid generating built-in MemoryEffect interfaces when processing any .td file that includes SideEffectInterfaceBase.td. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D91493 | 5 年前 | |
[mlir] Add support for interface inheritance This allows for interfaces to define a set of "base classes", which are interfaces whose methods/extra class decls/etc. should be inherited by the derived interface. This more easily enables combining interfaces and their dependencies, without lots of awkard casting. Additional implicit conversion operators also greatly simplify the conversion process. One other aspect of this "inheritance" is that we also implicitly add the base interfaces to the attr/op/type. The user can still add them manually if desired, but this should help remove some of the boiler plate when an interface has dependencies. See https://discourse.llvm.org/t/interface-inheritance-and-dependencies-interface-method-visibility-interface-composition Differential Revision: https://reviews.llvm.org/D140198 | 3 年前 | |
Fix ODS verifier emission for DerivedAttr when Properties are enabled Differential Revision: https://reviews.llvm.org/D158679 | 2 年前 | |
[ODS] Use Adaptor Traits for Type Inference Author inferReturnTypes methods with the Op Adaptor by using the InferTypeOpAdaptor. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D155115 | 3 年前 | |
[mlir][NFC] Migrate rest of the dialects to the new fold API | 3 年前 | |
[mlir] Allows to query traits from types and attributes Types and attributes now have a hasTrait function that allow users to check if a type defines a trait. Also, AbstractType and AbstractAttribute has now a hasTraitFn field to carry the implementation of the hasTrait function of the concrete type or attribute. This patch also adds the remaining functions to access type and attribute traits in TableGen. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D105202 | 4 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
[mlir] Fix infinite recursion in alias initializer The alias initializer keeps a list of child indices around. When an alias is then marked as non-deferrable, all children are also marked non-deferrable. This is currently done naively which leads to an infinite recursion if using mutable types or attributes containing a cycle. This patch fixes this by adding an early return if the alias is already marked non-deferrable. Since this function is the only way to mark an alias as non-deferrable, it is guaranteed that if it is marked non-deferrable, all its children are as well, and it is not required to walk all the children. This incidentally makes the non-deferrable marking also O(n) instead of O(n^2) (although not performance sensitive obviously). Differential Revision: https://reviews.llvm.org/D158932 | 2 年前 | |
[NFC][Py Reformat] Reformat python files in mlir subdir This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black. If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. If you run into any problems, post to discourse about it and we will try to help. RFC Thread below: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential Revision: https://reviews.llvm.org/D150782 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 |