[mlir] Don't use Optional::getValue (NFC)
[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][cf] Implement missing SwitchOp::build functionReviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D126594
[mlir] Prevent argStorage relocationsThis fixes msan reports like https://reviews.llvm.org/P8285Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D124576
[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
show more ...
[mlir] Add support for operation-produced successor arguments in BranchOpInterfaceThis patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutabl
[mlir] Add support for operation-produced successor arguments in BranchOpInterfaceThis patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously `getMutableSuccessorOperands` for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path:```invoke %function(%0) label ^success ^error(%1 : i32)^error(%e: !error, %arg0 : i32): ...```The advantages of this are that any users of `BranchOpInterface` can still argue over remaining block argument operands (such as `%1` in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc.The way this patch implements that functionality is via a new class called `SuccessorOperands`, which is now returned by `getSuccessorOperands`. It basically contains an `unsigned` denoting how many operator produced operands exist, as well as a `MutableOperandRange`, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of `SuccessorOperands` is to provide various utility functions to modify and query the successor arguments from a `BranchOpInterface`.Differential Revision: https://reviews.llvm.org/D123062
[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] Split out a new ControlFlow dialect from StandardThis dialect is intended to model lower level/branch based control-flow constructs. The initial setof operations are: AssertOp, BranchOp, Co
[mlir] Split out a new ControlFlow dialect from StandardThis dialect is intended to model lower level/branch based control-flow constructs. The initial setof operations are: AssertOp, BranchOp, CondBranchOp, SwitchOp; all split out from the currentstandard dialect.See https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D118966