Introduces a hasRank() method to make checking for rank a bit easier.
This is partially to make it easier to make MemRef subclass ShapedType
--
PiperOrigin-RevId: 249927442
*) 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
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
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 emphasizes that it is potentially less constrained than you might desire (especially dialects will frequently not support all bit widths), and better matches the other type names, especially the container types.
--
PiperOrigin-RevId: 249718409
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
This avoids crashing when trying to dump an operation nested in a region that isn't yet attached to an operation, which is quite useful when debugging.
This alone won't be enough to print an unlink Operation, it'll display `<<UNLINKED INSTRUCTION>>`.
--
PiperOrigin-RevId: 249496388
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
The passed element type description is usually unnecessary, and it's just as valid to want to pass a description for the entire container. In either case there's an alternative (Separate element type def or a TypeAlias) and we don't need to pollute the main API.
To allow for this, I cleaned up the TF op definitions and added some additional utilities.
--
PiperOrigin-RevId: 249340979
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
Otherwise, GCC < 7 does not link in the dialect registration, fails to look up
the dialect in the context and cannot construct SDBM objects.
--
PiperOrigin-RevId: 249259758
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
