[mlir] Support getSuccessorInputs from parent opOps that implement `RegionBranchOpInterface` are allowed to indicate that they can branch back to themselves in `getSuccessorRegions`, but there is n
[mlir] Support getSuccessorInputs from parent opOps that implement `RegionBranchOpInterface` are allowed to indicate that they can branch back to themselves in `getSuccessorRegions`, but there is no API that allows them to specify the forwarded operands. This patch enables that by changing `getSuccessorEntryOperands` to accept `None`.Fixes #54928Reviewed By: rriddleDifferential Revision: https://reviews.llvm.org/D127239
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] Convert OpTrait::FunctionLike to FunctionOpInterfaceThis commit refactors the FunctionLike trait into an interface (FunctionOpInterface).FunctionLike as it is today is already a pseudo-inte
[mlir] Convert OpTrait::FunctionLike to FunctionOpInterfaceThis commit refactors the FunctionLike trait into an interface (FunctionOpInterface).FunctionLike as it is today is already a pseudo-interface, with many users checking thepresence of the trait and then manually into functionality implemented in thefunction_like_impl namespace. By transitioning to an interface, these accesses are muchcleaner (ideally with no direct calls to the impl namespace outside of the implementationof the derived function operations, e.g. for parsing/printing utilities).I've tried to maintain as much compatability with the current state as possible, whilealso trying to clean up as much of the cruft as possible. The general migration plan forcurrent users of FunctionLike is as follows:* function_like_impl -> function_interface_implRealistically most user calls should remove references to functions within this namespaceoutside of a vary narrow set (e.g. parsing/printing utilities). Calls to the attribute nameaccessors should be migrated to the `FunctionOpInterface::` equivalent, most everythingelse should be updated to be driven through an instance of the interface.* OpTrait::FunctionLike -> FunctionOpInterface`hasTrait` checks will need to be moved to isa, along with the other various Trait vsInterface API differences.* populateFunctionLikeTypeConversionPattern -> populateFunctionOpInterfaceTypeConversionPatternFixes #52917Differential Revision: https://reviews.llvm.org/D117272
[mlir] Added new RegionBranchTerminatorOpInterface and adapted uses of hasTrait<ReturnLike>.This CL adds a new RegionBranchTerminatorOpInterface to query information about operands that can bepass
[mlir] Added new RegionBranchTerminatorOpInterface and adapted uses of hasTrait<ReturnLike>.This CL adds a new RegionBranchTerminatorOpInterface to query information about operands that can bepassed to successor regions. Similar to the BranchOpInterface, it allows to freely define theinvolved operands. However, in contrast to the BranchOpInterface, it expects an additional regionnumber to distinguish between various use cases which might require different operands passed todifferent regions.Moreover, we added new utility functions (namely getMutableRegionBranchSuccessorOperands andgetRegionBranchSuccessorOperands) to query (mutable) operand ranges for operations equiped with theReturnLike trait and/or implementing the newly added interface. This simplifies reasoning aboutterminators in the scope of the nested regions.We also adjusted the SCF.ConditionOp to benefit from the newly added capabilities.Differential Revision: https://reviews.llvm.org/D105018
[mlir] Add support for querying the ModRef behavior from the AliasAnalysis classThis allows for checking if a given operation may modify/reference/or both a given value. Right now this API is limit
[mlir] Add support for querying the ModRef behavior from the AliasAnalysis classThis allows for checking if a given operation may modify/reference/or both a given value. Right now this API is limited to Value based memory locations, but we should expand this to include attribute based values at some point. This is left for future work because the rest of the AliasAnalysis API also has this restriction.Differential Revision: https://reviews.llvm.org/D101673
[mlir] LocalAliasAnalysis: Assume allocation scope to function scope if cannot determine betterIt helps when checking aliasing between AllocOp result and function arguments.Differential Revision:
[mlir] LocalAliasAnalysis: Assume allocation scope to function scope if cannot determine betterIt helps when checking aliasing between AllocOp result and function arguments.Differential Revision: https://reviews.llvm.org/D102557
[mlir] Add initial support for an alias analysis framework in MLIRThis revision adds a new `AliasAnalysis` class that represents the main alias analysis interface in MLIR. The purpose of this class
[mlir] Add initial support for an alias analysis framework in MLIRThis revision adds a new `AliasAnalysis` class that represents the main alias analysis interface in MLIR. The purpose of this class is not to hold the aliasing logic itself, but to provide an interface into various different alias analysis implementations. As it evolves this should allow for users to plug in specialized alias analysis implementations for their own needs, and have them immediately usable by other analyses and transformations.This revision also adds an initial simple generic alias, LocalAliasAnalysis, that provides support for performing stateless local alias queries between values. This class is similar in scope to LLVM's BasicAA.Differential Revision: https://reviews.llvm.org/D92343