[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir] Refactoring dialect and test code to use parseCommaSeparatedListIssue #55173Reviewed By: lattner, rriddleDifferential Revision: https://reviews.llvm.org/D124791
[mlir:PDLInterp] Refactor the implementation of result type inferrenceThe current implementation uses a discrete "pdl_interp.inferred_types"operation, which acts as a "fake" handle to a type range
[mlir:PDLInterp] Refactor the implementation of result type inferrenceThe current implementation uses a discrete "pdl_interp.inferred_types"operation, which acts as a "fake" handle to a type range. This op isused as a signal to pdl_interp.create_operation that types should beinferred. This is terribly awkward and clunky though:* This op doesn't have a byte code representation, and its conversion to bytecode kind of assumes that it is only used in a certain way. The current lowering is also broken and seemingly untested.* Given that this is a different operation, it gives off the assumption that it can be used multiple times, or that after the first use the value contains the inferred types. This isn't the case though, the resultant type range can never actually be used as a type range.This commit refactors the representation by removing the discreteInferredTypesOp, and instead adds a UnitAttr topdl_interp.CreateOperation that signals when the created operationsshould infer their types. This leads to a much much cleaner abstraction,a more optimal bytecode lowering, and also allows for better errorhandling and diagnostics when a created operation doesn't actuallysupport type inferrence.Differential Revision: https://reviews.llvm.org/D124587
show more ...
[AsmParser] Introduce a new "Argument" abstraction + supporting logicMLIR has a common pattern for "arguments" that uses syntaxlike `%x : i32 {attrs} loc("sourceloc")` which is implementedin adho
[AsmParser] Introduce a new "Argument" abstraction + supporting logicMLIR has a common pattern for "arguments" that uses syntaxlike `%x : i32 {attrs} loc("sourceloc")` which is implementedin adhoc ways throughout the codebase. The approach this usesis verbose (because it is implemented with parallel arrays) andinconsistent (e.g. lots of things drop source location info).Solve this by introducing OpAsmParser::Argument and make addRegion(which sets up BlockArguments for the region) take it. Convert theworld to propagating this down. This means that we correctlycapture and propagate source location information in a lot morecases (e.g. see the affine.for testcase example), and it alsosimplifies much code.Differential Revision: https://reviews.llvm.org/D124649
[AsmParser] Rework logic around "region argument parsing"The asm parser had a notional distinction between parsing anoperand (like "%foo" or "%4#3") and parsing a region argument(which isn't supp
[AsmParser] Rework logic around "region argument parsing"The asm parser had a notional distinction between parsing anoperand (like "%foo" or "%4#3") and parsing a region argument(which isn't supposed to allow a result number like #3).Unfortunately the implementation has two problems:1) It didn't actually check for the result number and reject it. parseRegionArgument and parseOperand were identical.2) It had a lot of machinery built up around it that paralleled operand parsing. This also was functionally identical, but also had some subtle differences (e.g. the parseOptional stuff had a different result type).I thought about just removing all of this, but decided that themissing error checking was important, so I reimplemented it witha `allowResultNumber` flag on parseOperand. This keeps thecodepaths unified and adds the missing error checks.Differential Revision: https://reviews.llvm.org/D124470
[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and
[mlir] Rename `OpAsmParser::OperandType` to `OpAsmParser::UnresolvedOperand`I am not sure about the meaning of Type in the name (was it meant be interpreted as Kind?), and given the importance and meaning of Type in the context of MLIR, its probably better to rename it. Given the comment in the source code, the suggestion in the GitHub issue and the final discussions in the review, this patch renames the OperandType to UnresolvedOperand.Fixes https://github.com/llvm/llvm-project/issues/54446Differential Revision: https://reviews.llvm.org/D122142
[mlir:PDLInterp][NFC] Switch to using prefixed accessorsPDLInterp is effectively an internal dialect, so there isn't a need tostage the switch.
[mlir][PDL] Define a new PDLInterp::FuncOp operation and drop uses of FuncOpDefining our own function operation allows for the PDL interpreterto be more self contained, and also removes any depend
[mlir][PDL] Define a new PDLInterp::FuncOp operation and drop uses of FuncOpDefining our own function operation allows for the PDL interpreterto be more self contained, and also removes any dependency on FuncOp;which is moving out of the Builtin dialect.Differential Revision: https://reviews.llvm.org/D121253
[mlir] Update uses of `parser`/`printer` ODS op field to `hasCustomAssemblyFormat`The parser/printer fields are deprecated and in the process of being removed.
[mlir][NFC] Update PDL operations to use `hasVerifier` instead of `verifier`The verifier field is deprecated, and slated for removal.Differential Revision: https://reviews.llvm.org/D118828
[mlir] Make locations required when adding/creating block argumentsBlockArguments gained the ability to have locations attached a while ago, but theyhave always been optional. This goes against th
[mlir] Make locations required when adding/creating block argumentsBlockArguments gained the ability to have locations attached a while ago, but theyhave always been optional. This goes against the core tenant of MLIR where locationinformation is a requirement, so this commit updates the API to require locations.Fixes #53279Differential Revision: https://reviews.llvm.org/D117633
[mlir] Drop the leading space when printing regionsThe leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leadin
[mlir] Drop the leading space when printing regionsThe leading space that is always printed at the beginning of regions is not consistent with other parts of the printing API. Moreover, this leading space can lead to undesirable assembly formats:```attr-dict-with-keyword $region```Prints as:```// Two spaces between `}` and `{`attributes {foo} { ... }```Moreover, the leading space results in the odd generic op format:```"test.op"() ( {...}) : () -> ()```Reviewed By: rriddle, mehdi_aminiDifferential Revision: https://reviews.llvm.org/D117411
Fix clang-tidy issues in mlir/ (NFC)Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D115956
Defines new PDLInterp operations needed for multi-root matching in PDL.This is commit 1 of 4 for the multi-root matching in PDL, discussed in https://llvm.discourse.group/t/rfc-multi-root-pdl-patte
Defines new PDLInterp operations needed for multi-root matching in PDL.This is commit 1 of 4 for the multi-root matching in PDL, discussed in https://llvm.discourse.group/t/rfc-multi-root-pdl-patterns-for-kernel-matching/4148 (topic flagged for review).These operations are:* pdl.get_accepting_ops: Returns a list of operations accepting the given value or a range of values at the specified position. Thus if there are two operations `%op1 = "foo"(%val)` and `%op2 = "bar"(%val)` accepting a value at position 0, `%ops = pdl_interp.get_accepting_ops of %val : !pdl.value at 0` will return both of them. This allows us to traverse upwards from a value to operations accepting the value.* pdl.choose_op: Iteratively chooses one operation from a range of operations. Therefore, writing `%op = pdl_interp.choose_op from %ops` in the example above will select either `%op1`or `%op2`.Testing: Added the corresponding test cases to mlir/test/Dialect/PDLInterp/ops.mlir.Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D108543
[mlir] Generare .cpp.inc files for dialects.* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.* Discussed in
[mlir] Generare .cpp.inc files for dialects.* Previously, we were only generating .h.inc files. We foresee the need to also generate implementations and this is a step towards that.* Discussed in https://llvm.discourse.group/t/generating-cpp-inc-files-for-dialects/3732/2* Deviates from the discussion above by generating a default constructor in the .cpp.inc file (and adding a tablegen bit that disables this in case if this is user provided).* Generating the destructor started as a way to flush out the missing includes (produces a link error), but it is a strict improvement on its own that is worth doing (i.e. by emitting key methods in the .cpp file, we root vtables in one translation unit, which is a non-controversial improvement).Differential Revision: https://reviews.llvm.org/D105070
[mlir][PDL] Add support for variadic operands and results in the PDL InterpreterThis revision extends the PDL Interpreter dialect to add support for variadic operands and results, with ranges of th
[mlir][PDL] Add support for variadic operands and results in the PDL InterpreterThis revision extends the PDL Interpreter dialect to add support for variadic operands and results, with ranges of these values represented via the recently added !pdl.range type. To support this extension, three new operations have been added that closely match the single variant:* pdl_interp.check_types : Compare a range of types with a known range.* pdl_interp.create_types : Create a constant range of types.* pdl_interp.get_operands : Get a range of operands from an operation.* pdl_interp.get_results : Get a range of results from an operation.* pdl_interp.switch_types : Switch on a range of types.This revision handles adding support in the interpreter dialect and the conversion from PDL to PDLInterp. Support for variadic operands and results in the bytecode will be added in a followup revision.Differential Revision: https://reviews.llvm.org/D95722
[mlir] Mark OpState::getAttrs() deprecated.Fix call sites.The method will be removed 2 weeks later.Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D97464
[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.hThis is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also remov
[mlir][Types][NFC] Move all of the builtin Type classes to BuiltinTypes.hThis is part of a larger refactoring the better congregates the builtin structures under the BuiltinDialect. This also removes the problematic "standard" naming that clashes with the "standard" dialect, which is not defined within IR/. A temporary forward is placed in StandardTypes.h to allow time for downstream users to replaced references.Differential Revision: https://reviews.llvm.org/D92435
[mlir][PDL] Add a PDL Interpreter DialectThe PDL Interpreter dialect provides a lower level abstraction compared to the PDL dialect, and is targeted towards low level optimization and interpreter c
[mlir][PDL] Add a PDL Interpreter DialectThe PDL Interpreter dialect provides a lower level abstraction compared to the PDL dialect, and is targeted towards low level optimization and interpreter code generation. The dialect operations encapsulates low-level pattern match and rewrite "primitives", such as navigating the IR (Operation::getOperand), creating new operations (OpBuilder::create), etc. Many of the operations within this dialect also fuse branching control flow with some form of a predicate comparison operation. This type of fusion reduces the amount of work that an interpreter must do when executing.An example of this representation is shown below:```mlir// The following high level PDL pattern:pdl.pattern : benefit(1) { %resultType = pdl.type %inputOperand = pdl.input %root, %results = pdl.operation "foo.op"(%inputOperand) -> %resultType pdl.rewrite %root { pdl.replace %root with (%inputOperand) }}// May be represented in the interpreter dialect as follows:module { func @matcher(%arg0: !pdl.operation) { pdl_interp.check_operation_name of %arg0 is "foo.op" -> ^bb2, ^bb1 ^bb1: pdl_interp.return ^bb2: pdl_interp.check_operand_count of %arg0 is 1 -> ^bb3, ^bb1 ^bb3: pdl_interp.check_result_count of %arg0 is 1 -> ^bb4, ^bb1 ^bb4: %0 = pdl_interp.get_operand 0 of %arg0 pdl_interp.is_not_null %0 : !pdl.value -> ^bb5, ^bb1 ^bb5: %1 = pdl_interp.get_result 0 of %arg0 pdl_interp.is_not_null %1 : !pdl.value -> ^bb6, ^bb1 ^bb6: pdl_interp.record_match @rewriters::@rewriter(%0, %arg0 : !pdl.value, !pdl.operation) : benefit(1), loc([%arg0]), root("foo.op") -> ^bb1 } module @rewriters { func @rewriter(%arg0: !pdl.value, %arg1: !pdl.operation) { pdl_interp.replace %arg1 with(%arg0) pdl_interp.return } }}```Differential Revision: https://reviews.llvm.org/D84579