| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Modules can now contain more than just Functions, this just updates the iteration API to reflect that. The 'begin'/'end' methods have also been updated to iterate over opaque Operations.
PiperOrigin-RevId: 257099084
|
|
|
|
|
|
| |
As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction.
PiperOrigin-RevId: 256196193
|
|
|
|
|
|
| |
Function.
PiperOrigin-RevId: 255988352
|
|
|
|
|
|
| |
Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed).
PiperOrigin-RevId: 255983022
|
|
|
|
|
|
|
|
|
|
| |
Type conversion does not necessarily affect all types, some of them may remain
untouched. The type conversion tool from the dialect conversion framework will
unconditionally insert a temporary cast operation from the type to itself
anyway, and will try to materialize it to a real conversion operation if there
are remaining uses. Simply use the original value instead.
PiperOrigin-RevId: 255975450
|
|
|
|
|
|
|
|
| |
conversion must persist after the conversion has finished.
During conversion, if a type conversion has dangling uses a type conversion must persist after conversion has finished to maintain valid IR. In these cases, we now query the TypeConverter to materialize a conversion for us. This allows for the default case of a full conversion to continue working as expected, but also handle the degenerate cases more robustly.
PiperOrigin-RevId: 255637171
|
|
|
|
|
|
|
|
| |
into the mlir namespace.
Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups.
PiperOrigin-RevId: 255112791
|
|
|
|
| |
PiperOrigin-RevId: 255078768
|
|
|
|
| |
PiperOrigin-RevId: 254872695
|
|
|
|
|
|
| |
To support these mappings a hook must be overridden on the type converter: 'materializeConversion' :to generate a cast operation from the new types to the old type. This operation is automatically erased if all uses are removed, otherwise it remains in the IR for the user to handle.
PiperOrigin-RevId: 254411383
|
|
|
|
|
|
| |
parent region for the insertion position. This allows for inlining the given region into the end of another region.
PiperOrigin-RevId: 254367375
|
|
|
|
|
|
| |
what the function is actually checking.
PiperOrigin-RevId: 254141073
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Support for 1->0 type mappings, i.e. when the argument is being removed.
* Reordering types when converting a type signature.
* Adding new inputs when converting a type signature.
This cl also lays down the initial foundation for supporting 1->N type mappings, but full support will come in a followup.
Moving forward, function signature changes will be driven by populating a SignatureConversion instance. This class contains all of the necessary information for adding/removing/remapping function signatures; e.g. addInputs, addResults, remapInputs, etc.
PiperOrigin-RevId: 254064665
|
|
|
|
|
|
|
|
|
|
|
|
| |
initial cost model favors specific patterns based upon two criteria:
1) Lowest minimum pattern stack depth when legalizing.
- This leads the system to favor patterns that have lower legalization stacks, i.e. represent a more direct mapping to the target.
2) Pattern benefit.
- When considering multiple patterns with the same legalization depth, this favors patterns with a larger specified benefit.
PiperOrigin-RevId: 252713470
|
|
|
|
|
|
| |
consistent, and move a file functions to the source file.
PiperOrigin-RevId: 252639629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the support for region-containing operations to the dialect
conversion framework in order to support the conversion of affine control-flow
operations into the standard control flow with branches. Regions that belong
to an operation are converted before the operation itself. The
DialectConversionPattern can therefore access the converted regions of the
original operation and process them further if necessary. In particular, the
conversion is allowed to move the blocks from the original region to other
regions and to split blocks into multiple blocks. All block manipulations must
be performed through the PatternRewriter to ensure they will be undone if the
conversion fails.
Port the pass converting from the affine dialect (loops and ifs with bodies as
regions) to the standard dialect (branch-based cfg) to use DialectConversion in
order to exercise this new functionality. The modification to the lowering
functions are minor and are focused on using the PatterRewriter instead of
directly modifying the IR.
PiperOrigin-RevId: 252625169
|
|
|
|
|
|
| |
dialects as opposed to individual operations. This allows for better support of unregistered operations, as well as removing the need to collect all of the operations for a given dialect(which may be very expensive).
PiperOrigin-RevId: 251943590
|
|
|
|
|
|
| |
drops the default "always succeed" match override to better align with RewritePattern.
PiperOrigin-RevId: 251941625
|
|
|
|
|
|
| |
lowering identity(passthrough) operations to the same resultant type as the original operation.
PiperOrigin-RevId: 251665492
|
|
|
|
|
|
| |
any newly created value mappings.
PiperOrigin-RevId: 251658984
|
|
|
|
|
|
| |
instead of a function.
PiperOrigin-RevId: 251563898
|
|
|
|
|
|
|
|
|
|
| |
traversal helpers.
- added a typed walk to Block (matching the equivalent on Function)
- added token parsers (incl optional variants) for : and (
- added applyConversionPatterns that takes a list of functions to apply patterns to
PiperOrigin-RevId: 251481608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversions. Multi-level conversions are those that require multiple patterns to be applied before an operation is completely legalized. This essentially means that conversion patterns do not have to directly generate legal operations, and may be chained together to produce legal code.
To accomplish this, moving forward users will need to provide a legalization target that defines what operations are legal for the conversion. A target can mark an operation as legal by providing a specific legalization action. The initial actions are:
* Legal
- This action signals that every instance of the given operation is legal,
i.e. any combination of attributes, operands, types, etc. is valid.
* Dynamic
- This action signals that only some instances of a given operation are legal. This
allows for defining fine-tune constraints, like say std.add is only legal when
operating on 32-bit integers.
An example target is shown below:
struct MyTarget : public ConversionTarget {
MyTarget(MLIRContext &ctx) : ConversionTarget(ctx) {
// All operations in the LLVM dialect are legal.
addLegalDialect<LLVMDialect>();
// std.constant op is always legal on this target.
addLegalOp<ConstantOp>();
// std.return op has dynamic legality constraints.
addDynamicallyLegalOp<ReturnOp>();
}
/// Implement the custom legalization handler to handle
/// std.return.
bool isLegal(Operation *op) override {
// Process the dynamic handling for a std.return op (and any others that were
// marked "dynamic").
...
}
};
PiperOrigin-RevId: 251289374
|
|
|
|
|
|
|
|
| |
construction. This simplifies building the conversion pattern list from multiple sources.
--
PiperOrigin-RevId: 249930583
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249857277
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, FunctionConverter::convertRegion in the DialectConversion framework
was implemented as a function template because it was creating a new region in
the parent object, which could have been an op or a function. Since
DialectConversion now operates in place, new region is no longer created so
there is no need for convertRegion to be aware of the parent, only of the error
reporting location.
--
PiperOrigin-RevId: 249826392
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249678839
|
|
|
|
|
|
|
|
| |
DialectConversion class is only necessary for type signature changes(block arguments or function arguments). This isn't always desired when performing a dialect conversion. This allows for those conversions without this need to run per function instead of per module.
--
PiperOrigin-RevId: 249657549
|
|
|
|
|
|
|
|
| |
any cloning. This works by caching all of the requested pattern rewrite operations, e.g. replace operation, and only applying them on a completely successful conversion.
--
PiperOrigin-RevId: 249490306
|
|
|
|
|
|
|
|
| |
(until C++17)
--
PiperOrigin-RevId: 248990338
|
|
|
|
|
|
|
|
| |
DialectConversionPattern.
--
PiperOrigin-RevId: 248980810
|
|
|
|
|
|
|
|
|
|
| |
operate in-place, as opposed to incrementally constructing a new function. This is crucial to allowing the use of non type-conversion patterns(normal RewritePatterns) as part of the conversion process.
The converter now works by inserting fake producer operations when replacing the results of an existing operation with values of a different, now legal, type. These fake operations are guaranteed to never escape the converter.
--
PiperOrigin-RevId: 248969130
|
|
|
|
|
|
|
|
| |
instead of Pattern. This simplifies the infrastructure a bit by being able to reuse PatternRewriter and the RewritePatternMatcher, but also starts to lay the groundwork for a more generalized legalization framework that can operate on DialectOpConversions as well as normal RewritePatterns.
--
PiperOrigin-RevId: 248836492
|
|
|
|
|
|
|
|
| |
Transforms/ by using the new diagnostic infrastructure.
--
PiperOrigin-RevId: 246955332
|
|
|
|
|
|
|
|
|
|
| |
and, transitively, access to the context.
This also fixes a bug where FunctionAttrs were not being remapped for function and function argument attributes.
--
PiperOrigin-RevId: 246876924
|
|
|
|
|
|
|
|
|
|
| |
matches the operation.
This is the same logic as the PatterRewriter.
--
PiperOrigin-RevId: 242287241
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242031201
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dialect conversion currently clones the operations that did not match any
pattern. This includes cloning any regions that belong to these operations.
Instead, apply conversion recursively to the nested regions.
Note that if an operation matched one of the conversion patterns, it is up to
the pattern rewriter to fill in the regions of the converted operation. This
may require calling back to the converter and is left for future work.
PiperOrigin-RevId: 240872410
|
|
|
|
| |
PiperOrigin-RevId: 240636130
|
|
|
|
|
|
| |
*Op classes. This is a net reduction by almost 400LOC.
PiperOrigin-RevId: 239972443
|
|
|
|
| |
PiperOrigin-RevId: 239144675
|
|
|
|
|
|
| |
NFC. This is step 1/n to specifying regions as parts of any operation.
PiperOrigin-RevId: 238472370
|
|
|
|
|
|
| |
namespace.
PiperOrigin-RevId: 237712180
|
|
|
|
|
|
| |
xla/tensorflow/etc.
PiperOrigin-RevId: 237537341
|
|
|
|
| |
PiperOrigin-RevId: 237339277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug: previously, during conversion function argument
attributes were neither beings passed through nor converted. This fix
extends DialectConversion to allow for simultaneous conversion of the
function type and the argument attributes.
This was important when lowering MLIR to LLVM where attribute
information (e.g. noalias) needs to be preserved in MLIR(LLVMDialect).
Longer run it seems reasonable that we want to convert both the
function attribute and its type and the argument attributes, but that
requires a small refactoring in Function.h to aggregate these three
fields in an inner struct, which will require some discussion.
PiperOrigin-RevId: 236709409
|
|
|
|
|
|
| |
just a utility class that performs dialect conversion on a provided module.
PiperOrigin-RevId: 235194067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function types are built-in in MLIR and affect the validity of the IR itself.
However, advanced target dialects such as the LLVM IR dialect may include
custom function types. Until now, dialect conversion was expecting function
types not to be converted to the custom type: although the signatures was
allowed to change, the outer type must have been an mlir::FunctionType. This
effectively prevented dialect conversion from creating instructions that
operate on values of the custom function type.
Dissociate function signature conversion from general type conversion.
Function signature conversion must still produce an mlir::FunctionType and is
used in places where built-in types are required to make IR valid. General
type conversion is used for SSA values, including function and block arguments
and function results.
Exercise this behavior in the LLVM IR dialect conversion by converting function
types to LLVM IR function pointer types. The pointer to a function is chosen
to provide consistent lowering of higher-order functions: while it is possible
to have a value of function type, it is not possible to create a function type
accepting a returning another function type.
PiperOrigin-RevId: 234124494
|
|
|
|
|
|
| |
terminate a block and have block operands. This allows for any operation to hold block operands. It also introduces the notion that unregistered operations may terminate a block. As such, the 'isTerminator' api on Instruction has been split into 'isKnownTerminator' and 'isKnownNonTerminator'.
PiperOrigin-RevId: 233076831
|
|
|
|
| |
PiperOrigin-RevId: 232323671
|