| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This will allow for cleanly using a rewriter for multiple different regions.
PiperOrigin-RevId: 257845371
|
|
|
|
|
|
| |
This field wasn't updated as the insertion point changed, making it potentially dangerous given the multi-level of MLIR(e.g. 'createBlock' would always insert the new block in 'region'). This also allows for building an OpBuilder with just a context.
PiperOrigin-RevId: 257829135
|
|
|
|
|
|
| |
The GreedyPatternRewriteDriver currently does not notify the OperationFolder when constants are removed as part of a pattern match. This materializes in a nasty bug where a different operation may be allocated to the same address. This causes an assertion in the OperationFolder when it gets notified of the new operations removal.
PiperOrigin-RevId: 257817627
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL splits the lowering of affine to LLVM into 2 parts:
1. affine -> std
2. std -> LLVM
The conversions mostly consists of splitting concerns between the affine and non-affine worlds from existing conversions.
Short-circuiting of affine `if` conditions was never tested or exercised and is removed in the process, it can be reintroduced later if needed.
LoopParametricTiling.cpp is updated to reflect the newly added ForOp::build.
PiperOrigin-RevId: 257794436
|
|
|
|
|
|
| |
This allows for the attribute to hold symbolic references to other operations than FuncOp. This also allows for removing the dependence on FuncOp from the base Builder.
PiperOrigin-RevId: 257650017
|
|
|
|
|
|
|
|
|
|
|
| |
Standard load and store operations are evolving to be separated from the Affine
constructs. Special affine.load/store have been introduced to uphold the
restrictions of the Affine control flow constructs on their operands.
EDSC-produced loads and stores were originally intended to uphold those
restrictions as well so they should use affine.load/store instead of
std.load/store.
PiperOrigin-RevId: 257443307
|
|
|
|
|
|
| |
Module is a legacy name that only exists as a typedef of ModuleOp.
PiperOrigin-RevId: 257427248
|
|
|
|
| |
PiperOrigin-RevId: 257293379
|
|
|
|
| |
PiperOrigin-RevId: 257190161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parametric tiling can be used to extract outer loops with fixed number of
iterations. This in turn enables mapping to GPU kernels on a fixed grid
independently of the range of the original loops, which may be unknown
statically, making the kernel adaptable to different sizes. Provide a utility
function that also computes the parametric tile size given the range of the
loop. Exercise the utility function through a simple pass that applies it to
all top-level loop nests. Permutability or parallelism checks must be
performed before calling this utility function in actual passes.
Note that parametric tiling cannot be implemented in a purely affine way,
although it can be encoded using semi-affine maps. The choice to implement it
on standard loops is guided by them being the common representation between
Affine loops, Linalg and GPU kernels.
PiperOrigin-RevId: 257180251
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
These methods assume that a function is a valid builtin top-level operation, and removing these methods allows for decoupling FuncOp and IR/. Utility "getParentOfType" methods have been added to Operation/OpState to allow for querying the first parent operation of a given type.
PiperOrigin-RevId: 257018913
|
|
|
|
| |
PiperOrigin-RevId: 256579717
|
|
|
|
|
|
|
|
|
|
|
| |
affine.load/store/dma_start/dma_wait.
In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands).
Significant code changes occur here:
*) Vectorization: LoopAnalysis.cpp, Vectorize.cpp
*) Affine Transforms: Transforms/Utils/Utils.cpp
PiperOrigin-RevId: 256395088
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 256029944
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 255960171
|
|
|
|
| |
PiperOrigin-RevId: 255908660
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
materializing constants.
The OperationFolder currently just inserts into the entry block of a Function, but regions may be isolated above, i.e. explicit capture only, and blindly inserting constants may break the invariants of these regions.
PiperOrigin-RevId: 254987796
|
|
|
|
| |
PiperOrigin-RevId: 254872695
|
|
|
|
| |
PiperOrigin-RevId: 254847773
|
|
|
|
|
|
| |
Instead put their impl in test/lib and link them into mlir-test-opt
PiperOrigin-RevId: 254837439
|
|
|
|
|
|
| |
also removes the unused 'NthRegionIsIsolatedFromAbove' trait as it was replaced with a more general 'IsIsolatedFromAbove'.
PiperOrigin-RevId: 254709704
|
|
|
|
|
|
| |
that materializes an attribute value with the given type. This effectively adds support for dialect specific constant values that have different invariants than std.constant. 'OperationFolder' is updated to use this new hook, or attempt to default to std.constant when legal.
PiperOrigin-RevId: 254570153
|
|
|
|
|
|
| |
Now that Locations are Attributes they contain a direct reference to the MLIRContext, i.e. the context can be directly accessed from the given location instead of being explicitly passed in.
PiperOrigin-RevId: 254568329
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Historically the pointer-based version of builders was used.
This CL uniformizes to OpBuilder &
PiperOrigin-RevId: 254280885
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
DenseElementsAttr.
PiperOrigin-RevId: 253910543
|
|
|
|
|
|
| |
LoopFusionUtils (NFC).
PiperOrigin-RevId: 253797886
|
|
|
|
|
|
|
|
| |
Arguably, this function is only useful for transformations and should not
pollute the main IR. Also make sure it accepts a the resulting container
by-reference instead of returning it.
PiperOrigin-RevId: 253622981
|
|
|
|
|
|
| |
will enable fusion of consumer loop nests into their producers in subsequent CLs.
PiperOrigin-RevId: 253601994
|
|
|
|
|
|
|
|
|
| |
This converts entire loops into threads/blocks. No check on the size of the
block or grid, or on the validity of parallelization is performed, it is under
the responsibility of the caller to strip-mine the loops and to perform the
dependence analysis before calling the conversion.
PiperOrigin-RevId: 253189268
|
|
|
|
|
|
| |
being a separate Attribute type. DenseElementsAttr provides a better internal representation for splat values as well as better API for accessing elements.
PiperOrigin-RevId: 253138287
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
error cases (NFC).
PiperOrigin-RevId: 252437616
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
operation with a given OpBuilder and automatically try to fold it, similarly to OpBuilder::createOrFold. The difference here is that these methods enable folding to constants in addition to existing values. This functionality is then used to replace linalg::FunctionConstants.
PiperOrigin-RevId: 251716247
|
|
|
|
|
|
| |
lowering identity(passthrough) operations to the same resultant type as the original operation.
PiperOrigin-RevId: 251665492
|