[mlir] Fixed ordering of pass statistics.The change makes sure the plain C string statistics namesare properly ordered.Differential Revision: https://reviews.llvm.org/D130122
[mlir] Fix warning `missing base in copy ctor`This suppresse annoying warning when building mlir.``` warning: base class ‘class mlir::PassWrapper<{anonymous}::TestStatisticPass, mlir::Operation
[mlir] Fix warning `missing base in copy ctor`This suppresse annoying warning when building mlir.``` warning: base class ‘class mlir::PassWrapper<{anonymous}::TestStatisticPass, mlir::OperationPass<void> >’ should be explicitly initialized in the copy constructor [-Wextra]```Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D126209
show more ...
Apply clang-tidy fixes for bugprone-copy-constructor-init in TestPassManager.cpp (NFC)
Print custom assembly on pass failure by defaultThe printer is now resilient to invalid IR and will already automaticallyfallback to the generic form on invalid IR. Using the generic printer onpa
Print custom assembly on pass failure by defaultThe printer is now resilient to invalid IR and will already automaticallyfallback to the generic form on invalid IR. Using the generic printer onpass failure was a conservative option before the printer was madefailsafe.Reviewed By: lattner, rriddle, jpienaar, bondhugulaDifferential Revision: https://reviews.llvm.org/D123915
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespaceFuncOp has been moved to the `func` namespace for a little over a month, theusing directive can be dropped now.
[mlir][NFC] Drop a few unnecessary includes from Pass.h
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implici
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implicit" fallback path to use the name of the type, instead of usinga static template variable (which breaks shared libraries). The major downside to thisis that it adds some additional initialization costs for the implicit path. Given theuse of type names for uniqueness in the fallback, we also no longer allow typesdefined in anonymous namespaces to have an implicit TypeID. To simplify definingan ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macrowas added to allow for explicitly defining a TypeID directly on an internal class.To help identify when types are using the fallback, `-debug-only=typeid` can beused to log which types are using implicit ids.This change generally only requires changes to the test passes, which are all definedin anonymous namespaces, and thus can't use the fallback any longer.Differential Revision: https://reviews.llvm.org/D122775
[mlir:PassOption] Rework ListOption parsing and add support for std::vector/SmallVector optionsListOption currently uses llvm::cl::list under the hood, but the usagesof ListOption are generally a
[mlir:PassOption] Rework ListOption parsing and add support for std::vector/SmallVector optionsListOption currently uses llvm::cl::list under the hood, but the usagesof ListOption are generally a tad different from llvm::cl::list. Thiscommit codifies this by making ListOption implicitly comma separated,and removes the explicit flag set for all of the current list options.The new parsing for comma separation of ListOption also adds in supportfor skipping over delimited sub-ranges (i.e. {}, [], (), "", ''). Thismore easily supports nested options that use those as part of theformat, and this constraint (balanced delimiters) is already codifiedin the syntax of pass pipelines.See https://discourse.llvm.org/t/list-of-lists-pass-option/5950 forrelated discussionDifferential Revision: https://reviews.llvm.org/D122879
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made FuncOp an operation (years ago). This commit handles thefunctional aspects of the move, but various aspects are left untouchedto ease migration: func::FuncOp is re-exported into mlir to reducethe actual API churn, the assembly format still accepts the unqualified`func`. These temporary measures will remain for a little while tosimplify migration before being removed.Differential Revision: https://reviews.llvm.org/D121266
[mlir] Fix missing verification after running an OpToOpAdaptorPassThe current decision of when to run the verifier is running on theassumption that nested passes can't affect the validity of the p
[mlir] Fix missing verification after running an OpToOpAdaptorPassThe current decision of when to run the verifier is running on theassumption that nested passes can't affect the validity of the parentoperation, which isn't true. Parent operations may attach any numberof constraints on nested operations, which may not necessarily becaptured (or shouldn't be captured) at a smaller granularity.This commit rectifies this by properly running the verifier after anOpToOpAdaptor pass. To avoid an explosive increase in compile time,we only run verification on the parent operation itself. To do this, aflag to mlir::verify is added to avoid recursive verification if it isn'tdesired.Fixes #54288Differential Revision: https://reviews.llvm.org/D121836
[mlir][Pass] Add support for an InterfacePass and pass filtering based on OperationNameThis commit adds a new hook Pass `bool canScheduleOn(RegisteredOperationName)` thatindicates if the given pas
[mlir][Pass] Add support for an InterfacePass and pass filtering based on OperationNameThis commit adds a new hook Pass `bool canScheduleOn(RegisteredOperationName)` thatindicates if the given pass can be scheduled on operations of the given type. This makes iteasier to define constraints on generic passes without a) adding conditional checks tothe beginning of the `runOnOperation`, or b) defining a new pass type that forwardsfrom `runOnOperation` (after checking the invariants) to a new hook. This new hook isused to implement an `InterfacePass` pass class, that represents a generic pass thatruns on operations of the given interface type.The PassManager will also verify that passes added to a pass manager can actually bescheduled on that pass manager, meaning that we will properly error when an Interfaceis scheduled on an operation that doesn't actually implement that interface.Differential Revision: https://reviews.llvm.org/D120791
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around,
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around, as we cansimplify filter out declarations when necessary within the pass. We canalso explore with better scheduling primitives to filter out declarationsat the pipeline level in the future.The definition of FunctionPass is left intact for now to allow time for downstreamusers to migrate.Differential Revision: https://reviews.llvm.org/D117182
Fix more clang-tidy cleanups in mlir/ (NFC)
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferenti
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferential Revision: https://reviews.llvm.org/D115309
[mlir:Pass] Generate a reproducer as early as possibleThis avoids keeping references to passes that may be freed bythe time that the pass manager has finished executing (in thenon-crash case).F
[mlir:Pass] Generate a reproducer as early as possibleThis avoids keeping references to passes that may be freed bythe time that the pass manager has finished executing (in thenon-crash case).Fixes PR#52069Differential Revision: https://reviews.llvm.org/D111106
Migrate MLIR test passes to the new registration APIMake sure they all define getArgument()/getDescription().Depends On D104421Differential Revision: https://reviews.llvm.org/D104426
[mlir] Resolve TODO and use the pass argument instead of the TypeID for registrationThis simplifies various pieces of code that interact with the pass registry, e.g. this removes the need to regist
[mlir] Resolve TODO and use the pass argument instead of the TypeID for registrationThis simplifies various pieces of code that interact with the pass registry, e.g. this removes the need to register passes to get accurate pass pipelines descriptions when generating crash reproducers.Differential Revision: https://reviews.llvm.org/D101880
[mlir] Add a new `print-ir-after-failure` IR pass printing flagThis flag will print the IR after a pass only in the case where the pass failed. This can be useful to more easily view the invalid IR
[mlir] Add a new `print-ir-after-failure` IR pass printing flagThis flag will print the IR after a pass only in the case where the pass failed. This can be useful to more easily view the invalid IR, without needing to print after every pass in the pipeline.Differential Revision: https://reviews.llvm.org/D101853
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part o
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested.Differential Revision: https://reviews.llvm.org/D102456
[mlir][BuiltinDialect] Resolve comments from D91571* Move ops to a BuiltinOps.h* Add file comments
[mlir][NFC] Remove references to Module.h and Function.hThese includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.Differential Revisi
[mlir][NFC] Remove references to Module.h and Function.hThese includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp.Differential Revision: https://reviews.llvm.org/D91572
[MLIR] Reapply: Adjust libMLIR building to more closely follow libClangThis reverts commit ab1ca6e60fc58b857cc5030ca6e024d20d919cb9.
Revert "[MLIR] Adjust libMLIR building to more closely follow libClang"This reverts commit 4f0f436749c264c16eb226c9b9b132e07e3650a6.This seems to show some compile dependence problems, and also b
Revert "[MLIR] Adjust libMLIR building to more closely follow libClang"This reverts commit 4f0f436749c264c16eb226c9b9b132e07e3650a6.This seems to show some compile dependence problems, and also breaks flang.
[MLIR] Adjust libMLIR building to more closely follow libClang- Exports MLIR targets to be used out-of-tree.- mimicks `add_clang_library` and `add_flang_library`.- Fixes libMLIR.soAfter https:/
[MLIR] Adjust libMLIR building to more closely follow libClang- Exports MLIR targets to be used out-of-tree.- mimicks `add_clang_library` and `add_flang_library`.- Fixes libMLIR.soAfter https://reviews.llvm.org/D77515 libMLIR.so was no longer containingany object files. We originally had a cludge there that made it work withthe static initalizers and when switchting away from that to the way theclang shlib does it, I noticed that MLIR doesn't create a `obj.{name}` target,and doesn't export it's targets to `lib/cmake/mlir`.This is due to MLIR using `add_llvm_library` under the hood, which addsthe target to `llvmexports`.Differential Revision: https://reviews.llvm.org/D78773[MLIR] Fix libMLIR.so and LLVM_LINK_LLVM_DYLIBPrimarily, this patch moves all mlir references to LLVM libraries intoeither LLVM_LINK_COMPONENTS or LINK_COMPONENTS. This enables magic inthe llvm cmake files to automatically replace reference to LLVM componentswith references to libLLVM.so when necessary. Among other things, thiscompletes fixing libMLIR.so, which has been broken for some configurationssince D77515.Unlike previously, the pattern is now that mlir libraries should almostalways use add_mlir_library. Previously, some libraries still usedadd_llvm_library. However, this confuses the export of targets for useout of tree because libraries specified with add_llvm_library are exportedby LLVM. Instead users which don't need/can't be linked into libMLIR.socan specify EXCLUDE_FROM_LIBMLIRA common error mode is linking with LLVM libraries outside of LINK_COMPONENTS.This almost always results in symbol confusion or multiply defined optionsin LLVM when the same object file is included as a static library andas part of libLLVM.so. To catch these errors more directly, there's nowmlir_check_all_link_libraries.To simplify usage of add_mlir_library, we assume that all mlirlibraries depend on LLVMSupport, so it's not necessary to separately specifyit.tested with:BUILD_SHARED_LIBS=on,BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB,BUILD_SHARED_LIBS=off + LLVM_BUILD_LLVM_DYLIB + LLVM_LINK_LLVM_DYLIB.By: Stephen Neuendorffer <[email protected]>Differential Revision: https://reviews.llvm.org/D79067[MLIR] Move from using target_link_libraries to LINK_LIBSThis allows us to correctly generate dependencies for derived targets,such as targets which are created for object libraries.By: Stephen Neuendorffer <[email protected]>Differential Revision: https://reviews.llvm.org/D79243Three commits have been squashed to avoid intermediate build breakage.
[mlir] Eliminate the remaining usages of cl::opt instead of PassOption.Summary: Pass options are a better choice for various reasons and avoid the need for static constructors.Differential Revisi
[mlir] Eliminate the remaining usages of cl::opt instead of PassOption.Summary: Pass options are a better choice for various reasons and avoid the need for static constructors.Differential Revision: https://reviews.llvm.org/D77707
12