The initial implementation of SDBM mistakenly swapped the order of variables in
the inequalities induced by a stripe equality: y = x # B actually implies
y - x <= 0 and x - y <= B - 1 rather than x - y <= 0 and y - x <= B - 1 as
implemented. Textual comments in the test files were correct but did not
correspond to the emitted IR. Round-tripping between SDBM and expression lists
was not affected because the wrong order was used in both directions of the
conversion. Use the correct order.
PiperOrigin-RevId: 251252980
When manipulating generic operations, such as in dialect conversion /
rewriting, it is often necessary to view a list of Values as operands to an
operation without creating the operation itself. The absence of such view
makes dialect conversion patterns, among others, to use magic numbers to obtain
specific operands from a list of rewritten values when converting an operation.
Introduce XOpOperandAdaptor classes that wrap an ArrayRef<Value *> and provide
accessor functions identical to those available in XOp. This makes it possible
for conversions to use these adaptors to address the operands with names rather
than rely on their position in the list. The adaptors are generated from ODS
together with the actual operation definitions.
This is another step towards making dialect conversion patterns specific for a
given operation.
Illustrate the approach on conversion patterns in the standard to LLVM dialect
conversion.
PiperOrigin-RevId: 251232899
Similar to arguments and results, now we require region definition in ops to
be specified as a DAG expression with the 'region' operator. This way we can
specify the constraints for each region and optionally give the region a name.
Two kinds of region constraints are added, one allowing any region, and the
other requires a certain number of blocks.
--
PiperOrigin-RevId: 250790211
This allow specifying $x to refer to an operand's named argument (operand or attribute) or result. Skip variadic operands/results for now pending autogenerated discussion of their accessors.
This adds a new predicate, following feedback on the naming but does not remove the old one. Post feedback I'll do that, potentially in follow up.
--
PiperOrigin-RevId: 250720003
This is in preparation for making MemRef a ShapedType. In general, a shaped type should be anything with shape, rank, and element type properties, so use sites shouldn't assume more than that.
I also pulled the trailing comma parsing out the parseElementsLiteralType (new name) method. It seems weird to have the method parse the type + a trailing comma, even if all call sites currently need that. It's surprising behavior without looking at the implementation.
--
PiperOrigin-RevId: 250558363
This op defines a SPIR-V module using a MLIR region. The region contains
one block. Module-level operations, including functions definitions,
are all placed in this block.
This CL extracts common definitions from SPIRVOps.td into SPIRVBase.td.
The new op is placed in SPIRVStructureOps.td.
--
PiperOrigin-RevId: 250522320
This CL adds lowering of linalg.for to LLVM IR and adds an IR test.
This also replaces the usage of affine.for with linalg.for and enables the LLVM IR path in the integration test.
--
PiperOrigin-RevId: 250503798
The affine.for operation has restrictions that make it suitable for dependence analysis. The Linalg dialect aims at being more general.
This CL introduces linalg.for, and its associated terminator, along with a simple roundtripping test.
A `linalg.for` only takes one value of index type for lower bound, upper bound and step.
Example usage:
```
linalg.for %iv = %lb to %ub step %step {
... // body
}
```
--
PiperOrigin-RevId: 250369722
Verify pattern specification, added benefit, named pattern and location recording using TestDialect. Naming is verified via explicitly adding named pattern to TestPatternDriver pass. Refactoring test to verify the desired functionality rather than generated code.
--
PiperOrigin-RevId: 250205618
This CL sets up the basic structure for a SPIR-V dialect: operation
definition specification, dialect registration, testing, etc.
A single op, FMul, is defined and tested to showcase.
The SPIR-V dialect aims to be a simple proxy for the SPIR-V binary format
to enable straightforward and lightweight conversion from/to the binary
format. Ops in this dialect should stay as the same semantic level and
try to be a mechanical mapping to the corresponding SPIR-V instructions;
but they can deviate representationally to allow using MLIR mechanisms.
--
PiperOrigin-RevId: 250040830
This does tracks the location by recording all the ops in the source pattern and using the fused location for the transformed op. Track the locations via the rewrite state which is a bit heavy weight, in follow up to change to matchAndRewrite this will be addressed (and need for extra array go away).
--
PiperOrigin-RevId: 249986555
*) Adds LoopFusionUtils which will expose a set of loop fusion utilities (e.g. dependence checks, fusion cost/storage reduction, loop fusion transformation) for use by loop fusion algorithms. Support for checking block-level fusion-preventing dependences is added in this CL (additional loop fusion utilities will be added in subsequent CLs).
*) Adds TestLoopFusion test pass for testing LoopFusionUtils at a fine granularity.
*) Adds unit test for testing dependence check for block-level fusion-preventing dependences.
--
PiperOrigin-RevId: 249861071
This better matches other container types. Seems better to do that, even though tuples are a little different, since they don't have a single element type.
Also fixed its description to mention the element type.
--
PiperOrigin-RevId: 249730341
This CL prepares for mixing lowering of tiled linalg operations to loops with load and store operations. In particular it is necessary to capture partial tile information in views. This CL makes slice ops during Linalg tiling properly stop at partial tile boundaries by implementing `min` with a `cmpi` and `select` over values of index type.
To be consistent with lowering to loops, the implementation of tiling also drops specifics of accessing values via ranges and instead uses ranges of the form
`[0, dim(view), 1]` for creating view slices. This simplifies the code for the implementation of tiling and utils.
This also allows removing restrictions around needing a View or SliceOp defined in the current function context (as well as all it RangeOps). The restriction removal is tested by making the dot test operate directly on views.
The above is still subject to folding of the linalg.dim operation left for a future CL.
At this time, mixing tiling and lowering to loops all the way to execution is not yet functional because affine.for does not allow arbitrarily defined values of index type as its operands.
The previously introduced linalg.range_intersection was not sufficient to capture the necessary information and still required dealing with max quantities.
A followup CL will remove linalg.range_intersection.
--
PiperOrigin-RevId: 249698823
This CL makes lowering to loops always be a:
```
%D = linalg.dim %view, constant : !linalg.view<...>
affine.for %ix = %c0 to %D {
...
}
```
This form composes correctly with tiling and is also the proper way to emit loops from views that across function boundaries.
The previous version that would extract the range_min/max/step was composing incorrectly with tiling (i.e. would shift by range_min both in the loop bounds and in the slice) and would not work across function boundaries.
The relevant tests are updated and a new test `dot_view`---which lowers to loops from views passed as function parameters---is added.
When additional context is available, the linalg.dim operations should be folded away but this is left for a future CL.
--
PiperOrigin-RevId: 249634712
* There is no longer a need to explicitly remap function attrs.
- This removes a potentially expensive call from the destructor of Function.
- This will enable some interprocedural transformations to now run intraprocedurally.
- This wasn't scalable and forces dialect defined attributes to override
a virtual function.
* Replacing a function is now a trivial operation.
* This is a necessary first step to representing functions as operations.
--
PiperOrigin-RevId: 249510802
EDSC builder test uses FileCheck to match the IR produced by EDSC in the
textual order. For mathematical operations, EDSC relies on overloaded
operators. Since they are essentially function calls, the order of evaluation
of their operands is unspecified and differs between compilers. Do not rely on
a specific order of operands and just check they are all emitted before the
last operation. Give names to matched SSA values in order to make sure the
right operands are used in relevant places.
--
PiperOrigin-RevId: 249494995
Establish the following convention:
1. Container class types end in "Of" (e.g. TensorOf) and take a list of allowed types.
2. An X container where only a single type is allowed is called TypeX (e.g. I32Tensor).
3. An X container where any type is allowed is called AnyX (e.g. AnyTensor).
--
PiperOrigin-RevId: 249281018
MLIRContext does not have to be aware of the SDBM unique data structures
directly. Move the SDBM storage uniquer from MLIRContext to the SDBM dialect
instance. Expressions that previously required a context to be constructed now
require an instance of the dialect in order to access the uniquer. While they
could look up the dialect in the context, it would have introduced a rather
expensive lookup into each construction. Instead, the caller is expected to
obtain the dialect instance and cache it.
--
PiperOrigin-RevId: 249245199
We now have sufficient extensibility in dialects to move attribute components
such as SDBM out of the core IR into a dedicated dialect and make them
optional. Introduce an SDBM dialect and move the code. This is a mostly
non-functional change.
--
PiperOrigin-RevId: 249244802
This adds the basic passes needed and ties them into mlir-opt. Also adds two specific unit tests that exercise them.
Next step is a standalone quantizer tool and additional cleanup.
Tested:
ninja check-mlir
--
PiperOrigin-RevId: 249167690
Using ArrayRef introduces issues with the order of evaluation between a constructor and
the arguments of the subsequent calls to the `operator()`.
As a consequence the order of captures is not well-defined can go wrong with certain compilers (e.g. gcc-6.4).
This CL fixes the issue by using lambdas in lieu of ArrayRef.
--
PiperOrigin-RevId: 249114775
Alex Zinenko