| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Add support for VariadicOfVariadic operands This revision adds native ODS support for VariadicOfVariadic operand groups. An example of this is the SwitchOp, which has a variadic number of nested operand ranges for each of the case statements, where the number of case statements is variadic. Builtin ODS support allows for generating proper accessors for the nested operand ranges, builder support, and declarative format support. VariadicOfVariadic operands are supported by providing a segment attribute to use to store the operand groups, mapping similarly to the AttrSizedOperand trait (but with a user defined attribute name). build methods for VariadicOfVariadic operand expect inputs of the form ArrayRef<ValueRange>. Accessors for the variadic ranges return a new OperandRangeRange type, which represents a contiguous range of OperandRange. In the declarative assembly format, VariadicOfVariadic operands and types are by default formatted as a comma delimited list of value lists: (<value>, <value>), (), (<value>). Differential Revision: https://reviews.llvm.org/D107774 | 4 年前 | |
Fix crash in ODS backend for Type/Attr when an incorrect construct is used for Type/Attr Instead of crashing, try to print a useful error message. | 2 年前 | |
[mlir] Use std::optional instead of None in comments (NFC) This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[mlir][ods] add mechanism for deprecating an OpBuilder in ODS This allows discouraging the use of specific build methods of an op by having TableGen generate C++ code, instructing the C++ compiler to warn on use of the build method. The implementation uses the C++14 [[deprecated(...)]] for this purpose. I considered using LLVM_DEPRECATED, but thought requiring a fix-it was not necassery, nor would the syntax in ODS have been very nice. My motivation for this change is that in the future I'd like to deprecate the use build methods in the LLVM Dialect, not using explicit pointer types for ops such as llvm.load or llvm.alloca`, which makes the code not future proof for opaque pointers. In-tree has to be clean first before I could commit such a change of course, but I thought the initial infrastructure change could already be submitted. Differential Revision: https://reviews.llvm.org/D143190 | 3 年前 | |
Convert MLIR IndentedOstream to header only. This class has been causing me no end of grief for a long time, and the way it is used by mlir-tblgen is technically an ODR violation in certain situations. Due to the way that the build is layered, it is important that the MLIR tablegen libraries only depend on the LLVM tablegen libraries, not on anything else (like MLIRSupport). It has to be this way because these libraries/binaries are special and must pre-exist the full shared libraries. Therefore, the dependency chain must be clean (and static). At some point, someone pulled out a separate build target for just IndendedOstream in an attempt to satisfy the constraint. But because it is weird in different ways, this target was never installed properly as part of distributions, etc -- this causes problems for downstreams seeking to build a tblggen binary that doesn't itself have ODR/shared library problems. I was attempting to fix the distribution stuff but just opted to collapse this into a header-only library and not try to solve this with build layering. I think this is the safest and the least bad thing for such a dep. This also makes for a clean comment that actually explains the constraint (which I was having trouble verbalizing with the weird subset dependency). Differential Revision: https://reviews.llvm.org/D153393 | 3 年前 | |
[mlir][ods] add mechanism for deprecating an OpBuilder in ODS This allows discouraging the use of specific build methods of an op by having TableGen generate C++ code, instructing the C++ compiler to warn on use of the build method. The implementation uses the C++14 [[deprecated(...)]] for this purpose. I considered using LLVM_DEPRECATED, but thought requiring a fix-it was not necassery, nor would the syntax in ODS have been very nice. My motivation for this change is that in the future I'd like to deprecate the use build methods in the LLVM Dialect, not using explicit pointer types for ops such as llvm.load or llvm.alloca`, which makes the code not future proof for opaque pointers. In-tree has to be clean first before I could commit such a change of course, but I thought the initial infrastructure change could already be submitted. Differential Revision: https://reviews.llvm.org/D143190 | 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 年前 | |
[TableGen] llvm::Optional => std::optional | 3 年前 | |
Do not unnecessarily include StringSwitch.h | 3 年前 | |
[mlir] Move SymbolOpInterfaces "classof" check to a proper "extraClassOf" interface field SymbolOpInterface overrides the base classof to provide support for optionally implementing the interface. This is currently placed in the extraClassDeclarations, but that is kind of awkard given that it requires underlying knowledge of how the base classof is implemented. This commit adds a proper "extraClassOf" field to allow interfaces to implement this, which abstracts away the default classof logic. Differential Revision: https://reviews.llvm.org/D140197 | 3 年前 | |
[mlir][tblgen] Refact mlir-tblgen main into its own library This has previously been done for mlir-opt and mlir-reduce and roughly the same approach has been done here. The use case for having a separate library is that it is easier for downstream to make custom TableGen backends/executable that work on top of the utilities that are defined in mlir/TableGen. The customization point here is the same one as for any upstream TableGen backends: One can add a new generator by simply creating a global instance of mlir::GenRegistration. Differential Revision: https://reviews.llvm.org/D131112 | 3 年前 | |
[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 年前 | |
[mlir] Move casting calls from methods 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 patch updates all remaining uses of the deprecated functionality in mlir/. This was done with clang-tidy as described below and further modifications to GPUBase.td and OpenMPOpsInterfaces.td. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D151542 | 3 年前 | |
[TableGen] llvm::Optional => std::optional | 3 年前 | |
[mlir][tblgen] Fix emitting wrong index for either directive. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D149152 | 3 年前 | |
[mlir] Don't include SetVector.h (NFC) | 3 年前 | |
Update ODS variadic segments "magic" attributes to use native Properties The operand_segment_sizes and result_segment_sizes Attributes are now inlined in the operation as native propertie. We continue to support building an Attribute on the fly for getAttr("operand_segment_sizes") and setting the property from an attribute with setAttr("operand_segment_sizes", attr). A new bytecode version is introduced to support backward compatibility and backdeployments. Differential Revision: https://reviews.llvm.org/D155919 | 2 年前 | |
[mlir][ODS] Add support for variadic regions. Summary: This revision adds support for marking the last region as variadic in the ODS region list with the VariadicRegion directive. Differential Revision: https://reviews.llvm.org/D77455 | 6 年前 | |
[mlir] Add support for adding attribute+type traits/interfaces to tablegen defs This matches the current support provided to operations, and allows attaching traits, interfaces, and using the DeclareInterfaceMethods utility. This was missed when attribute/type generation was first added. Differential Revision: https://reviews.llvm.org/D100233 | 5 年前 | |
[llvm][ADT] Move TypeSwitch class from MLIR to LLVM This class implements a switch-like dispatch statement for a value of 'T' using dyn_cast functionality. Each Case<T> takes a callable to be invoked if the root value isa<T>, the callable is invoked with the result of dyn_cast<T>() as a parameter. Differential Revision: https://reviews.llvm.org/D78070 | 6 年前 | |
[ODS] Extra Concrete Declarations and Definitions under Traits Support extra concrete class declarations and definitions under NativeTrait that get injected into the class that specifies the trait. Extra declarations and definitions can be passed in as template arguments for NativeOpTraitNativeAttrTrait and NativeTypeTrait. Usage examples of this feature include: - Creating a wrapper Trait for authoring inferReturnTypes with the OpAdaptor by specifying necessary Op specific declarations and definitions directly in the trait - Refactoring the InferTensorType trait Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D154731 | 2 年前 | |
[TableGen] llvm::Optional => std::optional | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 2 年前 | ||
| 3 年前 |