summaryrefslogtreecommitdiff
path: root/mlir/tools
Commit message (Collapse)AuthorAgeFilesLines
* [mlir][GPU] Rename MLIRGPUOps CMake target to MLIRGPUDialectMatthias Springer2023-05-162-2/+2
| | | | | | This is for consistency with other dialects. Differential Revision: https://reviews.llvm.org/D150659
* [mlir][llvm] Add expect intrinsics.Tobias Gysi2023-05-161-0/+2
| | | | | | | | | The revision adds the LLVM expect and expect.with.probability intrinsics. Reviewed By: Dinistro, ftynse Differential Revision: https://reviews.llvm.org/D150643
* Add an operator == and != to properties, use it in DuplicateFunctionEliminationMehdi Amini2023-05-151-1/+14
| | | | Differential Revision: https://reviews.llvm.org/D150596
* [mlir] Move casting calls from methods to function callsTres Popp2023-05-121-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Caveats include: - This clang-tidy script probably has more problems. - This only touches C++ code, so nothing that is being generated. 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 first patch was created with the following steps. The intention is to only do automated changes at first, so I waste less time if it's reverted, and so the first mass change is more clear as an example to other teams that will need to follow similar steps. 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: https://github.com/llvm/llvm-project/compare/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. 4. Some changes have been deleted for the following reasons: - Some files had a variable also named cast - Some files had not included a header file that defines the cast functions - Some files are definitions of the classes that have the casting methods, so the code still refers to the method instead of the function without adding a prefix or removing the method declaration at the same time. ``` 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 git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\ mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\ mlir/lib/**/IR/\ mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\ mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\ mlir/test/lib/Dialect/Test/TestTypes.cpp\ mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\ mlir/test/lib/Dialect/Test/TestAttributes.cpp\ mlir/unittests/TableGen/EnumsGenTest.cpp\ mlir/test/python/lib/PythonTestCAPI.cpp\ mlir/include/mlir/IR/ ``` Differential Revision: https://reviews.llvm.org/D150123
* Fix UB passing nullptr to an EmptyProperties class when building OpAdaptorMehdi Amini2023-05-051-2/+27
| | | | | | | | A new forwarding constructor is introduced on the adaptor to take directly an OpaqueProperties object and do the nullptr checking and casting to avoid the boilerplate at callsites. Differential Revision: https://reviews.llvm.org/D150003
* [mlir][tblgen] Fix emitting wrong index for `either` directive.Chia-hung Duan2023-05-031-7/+8
| | | | | | Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D149152
* Try to fix CodeGenTypes issues in mlirNAKAMURA Takumi2023-05-032-1/+2
|
* Introduce MLIR Op PropertiesMehdi Amini2023-05-015-169/+840
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Introduce MLIR Op Properties"Mehdi Amini2023-05-015-840/+169
| | | | | | This reverts commit d572cd1b067f1177a981a4711bf2e501eaa8117b. Some bots are broken and investigation is needed before relanding.
* Introduce MLIR Op PropertiesMehdi Amini2023-05-015-169/+840
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. Differential Revision: https://reviews.llvm.org/D141742
* Remove deprecated `preloadDialectInContext` flag for MlirOptMain that has ↵Mehdi Amini2023-04-241-2/+1
| | | | | | | | been deprecated for 2 years See https://discourse.llvm.org/t/psa-preloaddialectincontext-has-been-deprecated-for-1y-and-will-be-removed/68992 Differential Revision: https://reviews.llvm.org/D149039
* [mlir] Dialect type/attr bytecode read/write generator.Jacques Pienaar2023-04-242-0/+468
| | | | | | | | | | | | | | | Tool to help generate dialect bytecode Attribute & Type reader/writing. Show usage by flipping builtin dialect. It helps reduce boilerplate when writing dialect bytecode attribute and type readers/writers. It is not an attempt at a generic spec mechanism but rather practically focussing on boilerplate reduction while also considering that it need not be the only in memory format and make it relatively easy to change. There should be some cleanup in follow up as we expand to more dialects. Differential Revision: https://reviews.llvm.org/D144820
* [mlir] Add a utility function to make a region isolated from above.Mahesh Ravishankar2023-04-201-0/+2
| | | | | | | | | | | | | | | | | | The utility functions takes a region and makes it isolated from above by appending to the entry block arguments that represent the captured values and replacing all uses of the captured values within the region with the newly added arguments. The captures values are returned. The utility function also takes an optional callback that allows cloning operations that define the captured values into the region during the process of making it isolated from above. The cloned value is no longer a captured values. The operands of the operation are then captured values. This is done transitively allow cloning of a DAG of operations into the region based on the callback. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D148684
* [mlir-cpu-runner] Add `export_executable_symbols` in CMakeAndrzej Warzynski2023-04-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is primarily about the change in "mlir/tools/mlir-cpu-runner/CMakeLists.txt". LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper) that will be defined in the executable when LLVM is linked statically. This change is consistent with how other tools within LLVM use LLJIT. It is required to make sure that: ``` $ mlir-cpu-runner --host-supports-jit ``` correctly returns `true` on platforms that do support JITting (in my case that's AArch64 Linux). The change in "mlir/lib/ExecutionEngine/CMakeLists.txt" is required to avoid ODR violations when symbols from `mlir-cpu-runner` are exported and when loading `libmlir_async_runtime.so` in `mlir-cpu-runner`. Specifically, to avoid `EnableABIBreakingChecks` being defined twice. For more context: * https://github.com/llvm/llvm-project/issues/61712 * https://github.com/llvm/llvm-project/issues/61856 * https://reviews.llvm.org/D146935 (this PR) This change relands ccdcfad0815296d8952438632d9abe6bc0a5258a Fixes #61856 Differential Revision: https://reviews.llvm.org/D146935
* [mlir][tblgen] Emit interface decls in definition order in the .td fileMatthias Springer2023-04-071-3/+8
| | | | | | | | Interface decls were previously sorted by name. This lead to problems when using interface inheritance when both interfaces are defined in the same .td file. The derived interface must appear after the base interface, otherwise the generated C++ will not compile. With this change, interfaces will compile as long as the base interface is defined before derived interfaces in the .td file. Differential Revision: https://reviews.llvm.org/D147689
* Implement Pass and Dialect plugins for mlir-optFabian Mora2023-04-061-0/+2
| | | | | | | | | | | | | | | | | | Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin implementation from the new pass manager. Currently the implementation only supports using the pass-pipeline option for adding passes. This restriction is imposed by the `PassPipelineCLParser` variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the parse options statically before parsing the cmd line args. ``` mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)" ``` Reviewed By: rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D147053
* Revert "Implement Pass and Dialect plugins for mlir-opt"Mehdi Amini2023-04-061-2/+0
| | | | | | This reverts commit e9b415870dc3036f989c03eb553473aed614658a. This landed without the right authorship.
* Implement Pass and Dialect plugins for mlir-optMehdi Amini2023-04-061-0/+2
| | | | | | | | | | | | | | Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin implementation from the new pass manager. Currently the implementation only supports using the pass-pipeline option for adding passes. This restriction is imposed by the `PassPipelineCLParser` variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the parse options statically before parsing the cmd line args. ``` mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)" ``` Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D147053
* Revert "Implement Pass and Dialect plugins for mlir-opt"Jacques Pienaar2023-04-061-2/+0
| | | | | | Breaks bot. This reverts commit d4c873b044aeebaa43e6989fb1f9606530ec60cf.
* Implement Pass and Dialect plugins for mlir-optFabian Mora2023-04-061-0/+2
| | | | | | | | | | | | | | Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin implementation from the new pass manager. Currently the implementation only supports using the pass-pipeline option for adding passes. This restriction is imposed by the `PassPipelineCLParser` variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the parse options statically before parsing the cmd line args. ``` mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)" ``` Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D147053
* [mlir][Interfaces] Add ValueBoundsOpInterfaceMatthias Springer2023-04-061-0/+2
| | | | | | | | | | | | Ops can implement this interface to specify lower/upper bounds for their result values and block arguments. Bounds can be specified for: * Index-type values * Dimension sizes of shapes values The bounds are added to a constraint set. Users can query this constraint set to compute bounds wrt. to a user-specified set of values. Only EQ bounds are supported at the moment. This revision also contains interface implementations for various tensor dialect ops, which illustrates how to implement this interface. Differential Revision: https://reviews.llvm.org/D145681
* [mlir][Analysis] Introduce LoopInfo in mlirChristian Ulmann2023-04-051-0/+2
| | | | | | | | | | This commit introduces an instantiation of LLVM's LoopInfo for CFGs in MLIR. To test the LoopInfo, a test pass is added the checks the analysis results for a set of CFGs. Reviewed By: ftynse Differential Revision: https://reviews.llvm.org/D147323
* [mlir][spirv-cpu-runner] Add missing call to registerPassManagerCLOptions().Adrian Kuegel2023-04-031-0/+1
| | | | Also fix tests, they were not calling FileCheck.
* [mlir] Fix ignoring return value warning.Adrian Kuegel2023-04-032-2/+4
|
* Revert "[mlir-cpu-runner] Add export_executable_symbols in CMake."Mitch Phillips2023-03-291-2/+0
| | | | | | | This reverts commit ccdcfad0815296d8952438632d9abe6bc0a5258a. Reason: Introduced an ODR that broke the ASan bots. See more information in Phabricator: https://reviews.llvm.org/D146935
* [mlir-cpu-runner] Add export_executable_symbols in CMake.Andrzej Warzynski2023-03-281-0/+2
| | | | | | | | | | | | | | LLJIT needs access to symbols (e.g. llvm_orc_registerEHFrameSectionWrapper) that will be defined in the executable when LLVM is linked statically. This change is consistent with how other tools within LLVM use LLJIT. It is required to make sure that `mlir-cpu-runner --host-supports-jit` correctly returns `true` on platforms that do support JITting (in my case that's AArch64 Linux). See https://github.com/llvm/llvm-project/issues/61712 for more context. Differential Revision: https://reviews.llvm.org/D146935
* [mlir] Implement pass utils for 1:N type conversions.Ingo Müller2023-03-272-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current dialect conversion does not support 1:N type conversions. This commit implements a (poor-man's) dialect conversion pass that does just that. To keep the pass independent of the "real" dialect conversion infrastructure, it provides a specialization of the TypeConverter class that allows for N:1 target materializations, a specialization of the RewritePattern and PatternRewriter classes that automatically add appropriate unrealized casts supporting 1:N type conversions and provide converted operands for implementing subclasses, and a conversion driver that applies the provided patterns and replaces the unrealized casts that haven't folded away with user-provided materializations. The current pass is powerful enough to express many existing manual solutions for 1:N type conversions or extend transforms that previously didn't support them, out of which this patch implements call graph type decomposition (which is currently implemented with a ValueDecomposer that is only used there). The goal of this pass is to illustrate the effect that 1:N type conversions could have, gain experience in how patterns should be written that achieve that effect, and get feedback on how the APIs of the dialect conversion should be extended or changed to support such patterns. The hope is that the "real" dialect conversion eventually supports such patterns, at which point, this pass could be removed again. Reviewed By: springerm Differential Revision: https://reviews.llvm.org/D144469
* Revert "[mlir] Implement pass utils for 1:N type conversions."Ingo Müller2023-03-272-3/+0
| | | | This reverts commit 9c4611f9c7a7055b18f0a30a4c9074b9917e4ab0.
* [mlir] Implement pass utils for 1:N type conversions.Ingo Müller2023-03-272-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current dialect conversion does not support 1:N type conversions. This commit implements a (poor-man's) dialect conversion pass that does just that. To keep the pass independent of the "real" dialect conversion infrastructure, it provides a specialization of the TypeConverter class that allows for N:1 target materializations, a specialization of the RewritePattern and PatternRewriter classes that automatically add appropriate unrealized casts supporting 1:N type conversions and provide converted operands for implementing subclasses, and a conversion driver that applies the provided patterns and replaces the unrealized casts that haven't folded away with user-provided materializations. The current pass is powerful enough to express many existing manual solutions for 1:N type conversions or extend transforms that previously didn't support them, out of which this patch implements call graph type decomposition (which is currently implemented with a ValueDecomposer that is only used there). The goal of this pass is to illustrate the effect that 1:N type conversions could have, gain experience in how patterns should be written that achieve that effect, and get feedback on how the APIs of the dialect conversion should be extended or changed to support such patterns. The hope is that the "real" dialect conversion eventually supports such patterns, at which point, this pass could be removed again. Reviewed By: springerm Differential Revision: https://reviews.llvm.org/D144469
* [mlir] Add missing registrations to runners.Adrian Kuegel2023-03-212-0/+4
|
* [mlir] Support lowering of dialect attributes attached to top-level modulesSergio Afonso2023-03-213-0/+3
| | | | | | | | | | | | | | | | | | | | | | | This patch supports the processing of dialect attributes attached to top-level module-type operations during MLIR-to-LLVMIR lowering. This approach modifies the `mlir::translateModuleToLLVMIR()` function to call `ModuleTranslation::convertOperation()` on the top-level operation, after its body has been lowered. This, in turn, will get the `LLVMTranslationDialectInterface` object associated to that operation's dialect before trying to use it for lowering prior to processing dialect attributes attached to the operation. Since there are no `LLVMTranslationDialectInterface`s for the builtin and GPU dialects, which define their own module-type operations, this patch also adds and registers them. The requirement for always calling `mlir::registerBuiltinDialectTranslation()` before any translation of MLIR to LLVM IR where builtin module operations are present is introduced. The purpose of these new translation interfaces is to succeed when processing module-type operations, allowing the lowering process to continue and to prevent the introduction of failures related to not finding such interfaces. Differential Revision: https://reviews.llvm.org/D145932
* Use *{Map,Set}::contains (NFC)Kazu Hirata2023-03-151-1/+1
|
* [ADT] Allow `llvm::enumerate` to enumerate over multiple rangesJakub Kuderski2023-03-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | This does not work by a mere composition of `enumerate` and `zip_equal`, because C++17 does not allow for recursive expansion of structured bindings. This implementation uses `zippy` to manage the iteratees and adds the stream of indices as the first zipped range. Because we have an upfront assertion that all input ranges are of the same length, we only need to check if the second range has ended during iteration. As a consequence of using `zippy`, `enumerate` will now follow the reference and lifetime semantics of the `zip*` family of functions. The main difference is that `enumerate` exposes each tuple of references through a new tuple-like type `enumerate_result`, with the familiar `.index()` and `.value()` member functions. Because the `enumerate_result` returned on dereference is a temporary, enumeration result can no longer be used through an lvalue ref. Reviewed By: dblaikie, zero9178 Differential Revision: https://reviews.llvm.org/D144503
* [ADT][mlir][NFCI] Do not use non-const lvalue-refs with enumerateJakub Kuderski2023-03-154-15/+16
| | | | | | | | | | | | | | | | | | | | | Replace references to enumerate results with either result_pairs (reference wrapper type) or structured bindings. I did not use structured bindings everywhere as it wasn't clear to me it would improve readability. This is in preparation to the switch to zip semantics which won't support non-const lvalue reference to elements: https://reviews.llvm.org/D144503. I chose to use values instead of const lvalue-refs because MLIR is biased towards avoiding `const` local variables. This won't degrade performance because currently `result_pair` is cheap to copy (size_t + iterator), and in the future, the enumerator iterator dereference will return temporaries anyway. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D146006
* [mlir][Affine] Add helper functions to allow reordering affine.apply ↵Nicolas Vasilache2023-03-141-0/+2
| | | | | | | | | | | | | | | | | operands and decompose the ops into smaller components Care is taken to order operands from least hoistable to most hoistable and to process subexpressions in the same order. This allows exposing more oppportunities for licm, cse and strength reduction. Such a step should typically be applied while we still have loops in the IR and just before lowering affine ops to arith. This is because the affine.apply canonicalization currently tries to maximally compose chains of affine.apply operations and could undo the effects of these decompositions. Depends on: D145784 Differential Revision: https://reviews.llvm.org/D145685
* [mlir][spirv][vector] Add pattern to convert reduction to SPIR-V dot prodJakub Kuderski2023-03-102-0/+3
| | | | | | | | | | | | This converts a specific form of `vector.reduction` to SPIR-V integer dot product ops. Add a new test pass to excercise this outside of the main vector to spirv conversion pass. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D145760
* [mlir][Parser] Make parse{Attribute,Type} null-terminate inputRahul Kayaith2023-03-031-4/+2
| | | | | | | | | | | | | | `parseAttribute` and `parseType` require null-terminated strings as input, but this isn't great considering the argument type is `StringRef`. This changes them to copy to a null-terminated buffer by default, with a `isKnownNullTerminated` flag added to disable the copying. closes #58964 Reviewed By: rriddle, kuhar, lattner Differential Revision: https://reviews.llvm.org/D145182
* [mlir][llvm] Add AliasAnalysis and AccessGroup interfaces to intrinsics.Tobias Gysi2023-03-021-8/+9
| | | | | | | | | | | | | | | | | | | This revision updates the memcpy, memove, and memset intrinsics to implement the AliasAnalysis and AccessGroup interfaces. The changes will enable the import and export of alias scope, tbaa, and access group metadata attached to these intrinsics. It also renames the requiresAliasScope flag to requiresAliasAnalysis since the intrinsics also support tbaa and not only access scope metadata. The revision still maintains the string based attribute lookup in the translation from MLIR to LLVMIR. Using the interfaces instead of the string based lookup is left to a followup revision. Depends on D144851 Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D144965
* [mlir][AsmParser] Improve parse{Attribute,Type} error handlingRahul Kayaith2023-03-011-2/+4
| | | | | | | | | | | | | | Currently these functions report errors directly to stderr, this updates them to use diagnostics instead. This also makes partially-consumed strings an error if the `numRead` parameter isn't provided (the docstrings already claimed this happened, but it didn't.) While here I also tried to reduce the number of overloads by switching to using default parameters. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D144804
* [mlir][SPIRV] Enable use of opaque-pointers in spirv-cpu-runnerMarkus Böck2023-02-241-2/+9
| | | | | | | | Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179 All passes required for lowering have already been successfully converted to allowing opaque-pointers. Switching the Spir-V runner to opaque-pointers is therefore only a matter of turning it on in these conversion passes. Regression tests also did not find any issues. Differential Revision: https://reviews.llvm.org/D144725
* [mlir][GPUToVulkan] Port conversion passes and `mlir-vulkan-runner` to ↵Markus Böck2023-02-241-4/+13
| | | | | | | | | | | | | | | | | opaque pointers Part of https://discourse.llvm.org/t/rfc-switching-the-llvm-dialect-and-dialect-lowerings-to-opaque-pointers/68179 This patch adds the new pass option 'use-opaque-pointers' to `-launch-func-to-vulkan` instructing the pass to emit LLVM opaque pointers instead of typed pointers. Note that the pass as it was previously implemented relied on the fact LLVM pointers carried an element type. The passed used this information to deduce both the rank of a "lowered-to-llvm" MemRef as well as the element type. Since the element type when using LLVM opaque pointers is completely erased it is not possible to deduce the element type. I therefore added a new attribute that is attached to the `vulkanLaunch` call alongside the binary blob and entry point name by the `-convert-gpu-launch-to-vulkan-launch` pass. It simply attaches a type array specifying the element types of each memref. This way the `-launch-func-to-vulkan` can simply read out the element type from the attribute. The rank can still be deduced from the auto-generated C interface from `FinalizeMemRefToLLVM`. This is admittedly a bit fragile but I was not sure whether it was worth the effort to also add a rank array attribute. As a last step, the use of opaque-pointers in `mlir-vulkan-runners` codegen pipeline was also enabled, since all covnersion passes used fully support it. Differential Revision: https://reviews.llvm.org/D144460
* [mlir] Complety remove old `fold` APIMarkus Böck2023-02-221-5/+1
| | | | | | | | Last part of https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374 All active users that I am aware of have already switched. Any remaining users will be forced to adopt their code after this patch has landed. Differential Revision: https://reviews.llvm.org/D144391
* [mlir][linalg][TransformOps] Connect hoistRedundantVectorTransfersNicolas Vasilache2023-02-201-2/+0
| | | | | | | | | Connect the hoistRedundantVectorTransfers functionality to the transform dialect. Authored-by: Quentin Colombet <quentin.colombet@gmail.com> Differential Revision: https://reviews.llvm.org/D144260
* Reland "[mlir][func] Use the generated pass options in func to llvm."Tobias Gysi2023-02-111-2/+4
| | | | | | | | | | | | | | | | | Update the FuncToLLVM pass to use the generated constructors and the generated pass option struct. The hand written constructor got out of sync after some refactorings. Using a generated constructor and options struct ensures the everything remains in sync. Reviewed By: zero9178 This reverts commit 39da46826da82c24ca4407c13ad7feb8e5dc32a1 and relands commit 771d9c05afc2515b474fb53db857716dfdfc1dcf which was originally reverted due to https://lab.llvm.org/buildbot#builders/61/builds/39694 Differential Revision: https://reviews.llvm.org/D143733
* [mlir] Add function for checking if a block is inside a loopTom Eccles2023-02-102-0/+3
| | | | | | | | | | | | | | | This function returns whether a block is nested inside of a loop. There can be three kinds of loop: 1) The block is nested inside of a LoopLikeOpInterface 2) The block is nested inside another block which is in a loop 3) There is a cycle in the control flow graph This will be useful for Flang's stack arrays pass, which moves array allocations from the heap to the stack. Special handling is needed when allocations occur inside of loops to ensure additional stack space is not allocated on each loop iteration. Differential Revision: https://reviews.llvm.org/D141401
* Revert "[mlir] Add function for checking if a block is inside a loop"Kiran Chandramohan2023-02-092-3/+0
| | | | | | Reverting since the shared library builds are failing. This reverts commit dcee187522c6e2e1a56ffc9b58bfe11c6ac44662.
* [mlir] Add function for checking if a block is inside a loopTom Eccles2023-02-092-0/+3
| | | | | | | | | | | | | | | This function returns whether a block is nested inside of a loop. There can be three kinds of loop: 1) The block is nested inside of a LoopLikeOpInterface 2) The block is nested inside another block which is in a loop 3) There is a cycle in the control flow graph This will be useful for Flang's stack arrays pass, which moves array allocations from the heap to the stack. Special handling is needed when allocations occur inside of loops to ensure additional stack space is not allocated on each loop iteration. Differential Revision: https://reviews.llvm.org/D141401
* [mlir][ods] add mechanism for deprecating an `OpBuilder` in ODSMarkus Böck2023-02-071-0/+3
| | | | | | | | | 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
* [mlir][scf] Fix builder of WhileOp with region builder arguments.Ingo Müller2023-02-071-0/+2
| | | | | | | | | | | | | | The overload of WhileOp::build with arguments for builder functions for the regions of the op was broken: It did not compute correctly the types (and locations) of the region arguments, which lead to failed assertions when the result types were different from the operand types. Specifically, it used the result types (and operand locations) for *both* regions, instead of the operand types (and locations) for the 'before' region and the result types (and loecations) for the 'after' region. Reviewed By: Mogball, mehdi_amini Differential Revision: https://reviews.llvm.org/D142952
* [mlir][llvm] Use tablegen for enum conversion.Tobias Gysi2023-02-031-0/+18
| | | | | | | | | | | | | | | | | The revision uses tablegen to convert multiple atomic and comparison related enums automatically rather than using hand coded functions in the import and export from and to LLVM IR. The revision also adds additional binary operation cases to the AtomicBinOp enum that have not been supported till now. It also introduces the possibility to define unsupported enum cases that exist only in LLVM IR and that are not imported into MLIR. These unsupported cases are helpful to handle sentinel values such as BAD_BINOP that LLVM commonly uses to terminate its enums. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D143189
View Lorry Controller Status