Historically, the LLVM IR dialect has been using the generic form of MLIR
operation syntax. It is verbose and often redundant. Introduce the custom
printing and parsing for all existing operations in the LLVM IR dialect.
Update the relevant documentation and tests.
--
PiperOrigin-RevId: 241617393
This CL starts the third part of the Linalg tutorial by adding support for ops to declare how they lower themselves to other ops.
Tests are added that demonstrate matmul lowering to a loop over matvec and matvec lowering to a loop over dot.
This is part of a list of CLs that add new Transforms and Analyses to Linalg3: it iseasier to integrate in small chunks.
As part of working with the TensorContractionBase template class and in an effort to add pieces incrementally without copying code, it is easiest to define operations ahead of time in Linalg2/TensorOps.h and gradually implement them as needed. This CL performs the necessary refactoring for this to happen.
--
PiperOrigin-RevId: 241605869
The second part of the Linalg tutorial introduces:
1. the TensorContractionBase type from which all tensor contractions derive;
2. a basic set of operations DotOp, MatvecOp and MatmulOp;
3. a helper function `createFullyComposedView` that walks the producers of a SliceOp up until the root ViewOp and returns a single ViewOp;
4. programmatic examples to test MLIR construction involving these types.
This CL also refactors file organization so that:
1. clients only need to include Ops.h and Types.h while keeping independent small files separate for the purpose of the tutorial;
2. each step of the tutorial has its own linalgxxx include directory and each include explicitly states in which part of the tutorial a particular concept was introduced.
Lastly the following cleanups are applied:
1. ValueOrSliceOp is removed in favor of simpler helper function.
2. methods that walk back the chain of ops are removed from the core ops and added to a separate Analysis.
3. various additional cleanups.
--
PiperOrigin-RevId: 241555769
This CL introduces Confined as a general mechanism to compose complex attribute
constraints out of more primitive ones. It's particularly useful for automatically
generating op definitions from some external source, where we can have random
combinations of primitive constraints and it would be impractical to define a case
for each of such combination.
Two primitive attribute constraints, IntMinValue and ArrayMinCount, are added to be
used together with Confined.
--
PiperOrigin-RevId: 241435955
The first part of the Linalg tutorial introduces:
1. the RangeType and ViewType;
2. operations on those, namely RangeOp, ViewOp and SliceOp;
3. programmatic examples to test MLIR construction involving these types, ops and affine.for loops (with a mock custom op called "some_consumer").
--
PiperOrigin-RevId: 241409949
This is making up for some differences in standard library and linker flags.
It also get rid of the requirement to build with RTTI.
--
PiperOrigin-RevId: 241348845
This CL adds EnumAttr as a general mechanism for modelling enum attributes. Right now
it is using StringAttr under the hood since MLIR does not have native support for enum
attributes.
--
PiperOrigin-RevId: 241334043
Example:
func @unknown_std_op() {
%0 = "std.foo_bar_op"() : () -> index
return
}
Will result in:
error: unregistered operation 'std.foo_bar_op' found in dialect ('std') that does not allow unknown operations
--
PiperOrigin-RevId: 241266009
have no standard ops for working with these yet, this is simply enough to
represent and round trip them in the printer and parser.
--
PiperOrigin-RevId: 241102728
This CL allows the programmatic control of the target hardware vector size when creating a MaterializeVectorsPass.
This is useful for registering passes for the tutorial.
PiperOrigin-RevId: 240996136
A integer number can be specified in the pattern definition and used as the
adjustment to the default benefit score in the generated rewrite pattern C++
definition.
PiperOrigin-RevId: 240994192
This CL removes the reliance of the vectorize pass on the specification of a `fastestVaryingDim` parameter. This parameter is a restriction meant to more easily target a particular loop/memref combination for vectorization and is mainly used for testing.
This also had the side-effect of restricting vectorization patterns to only the ones in which all memrefs were contiguous along the same loop dimension. This simple restriction prevented matmul to vectorize in 2-D.
this CL removes the restriction and adds the matmul test which vectorizes in 2-D along the parallel loops. Support for reduction loops is left for future work.
PiperOrigin-RevId: 240993827
These fail with:
could not convert ‘module’ from ‘llvm::orc::ThreadSafeModule’ to
‘llvm::Expected<llvm::orc::ThreadSafeModule>’
PiperOrigin-RevId: 240892583
Most of the tests have been ported to be unit-tests and this pass is problematic in the way it depends on TableGen-generated files. This pass is also non-deterministic during multi-threading and a blocker to turning it on by default.
PiperOrigin-RevId: 240889154
Alex Zinenko