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
PassRegistration with an optional constructor was introduced after the
LoopsToGPUPass, which resorted to deriving one pass from another as a means of
accepting options supplied as command-line arguments. Use PassRegistration with
constructor instead of defining a derived pass for LoopsToGPU. Also rename the
pass to better reflect its current nature.
PiperOrigin-RevId: 257786923
Linalg tiling pass was introduced before PassRegistration with an optional pass
constructor. It resorted to deriving a helper class from the origial pass
class in order to provide a default constructor with values obtained from
command line flags. Use PassRegistration with the optional pass constructor
instead, which avoids declaring an additional class.
PiperOrigin-RevId: 257786876
Remove the Function specific attribute verifier in favor of the general operation verifier. This also generalizes the function argument verifier to allow use for an argument attached to any region of any operation.
PiperOrigin-RevId: 257689962
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
Operations in a block can use a value defined in a dominating block. When a
block, and therefore all its operations, is deleted, the operations are not
allowed to have any remaining uses. Drop all uses of values in all blocks
before deleting them in FuncOp::eraseBody to avoid deleting an operation before
deleting the users of its results.
PiperOrigin-RevId: 257628002
Affine load and store operations take a variadic number of arguments, most of
which are interpreted as subscripts for the multi-dimensional memref they
access. Add a verifier check that ensures the number of operands is equal to
the number affine remapping inputs if present and to the rank of the acessed
memref otherwise. Although it is impossible to obtain such operations by
parsing the custom syntax, it is possible to construct them using the generic
syntax or programmatically.
PiperOrigin-RevId: 257605902
cuMemHostRegister expects the size of registered memory in bytes whereas the
memref descriptor in memref_t contains the number of elements. Get the actual
size in bytes instead.
PiperOrigin-RevId: 257589116
JSON spec into the SPIRBase.td file. This is done incrementally to
only import those opcodes that are needed, through use of the script
define_opcode.sh added.
PiperOrigin-RevId: 257517343
This changes the top-level module parser to handle the case where the top-level module is defined with the module operation syntax, i.e:
module ... {
}
The printer is also updated to always print the top-level module in this form. This allows for cleanly round-tripping the location and attributes of the top-level module.
PiperOrigin-RevId: 257492069
Windows build is not happy trying to convert a lambda into a constant reference
to a function in default arguments of the PassRegistration constructor. Define
two overloaded constructors instead and construct the lambda as a variable in
the constructor body.
PiperOrigin-RevId: 257448633
The ModulePrinter prints the newline now for children of the top-level module. This also fixes the location printing for functions as the location used to be printed on a different line.
PiperOrigin-RevId: 257447633
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
There is already a more general 'getParentOfType' method, and 'getModule' is likely to be misused as functions get placed within different regions than ModuleOp.
PiperOrigin-RevId: 257442243
AffineIfOp::build is not tested or exercised anywhere. It also perpetuates a questionable choice of encoding an optional region as an empty region which we would like to change in the future.
PiperOrigin-RevId: 257439832
This was an arbitrary restriction caused by the way that modules were printed. Now that that has been fixed, this restriction can be removed.
PiperOrigin-RevId: 257240329
Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations.
PiperOrigin-RevId: 257225069
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
Extend the utility that converts affine loop nests to support other types of
loops by abstracting away common behavior through templates. This also
slightly simplifies the existing Affine to GPU conversion by always passing in
the loop step as an additional kernel argument even though it is a known
constant. If it is used, it will be propagated into the loop body by the
existing canonicalization pattern and can be further constant-folded, otherwise
it will be dropped by canonicalization.
This prepares for the common loop abstraction that will be used for converting
to GPU kernels, which is conceptually close to Linalg loops, while maintaining
the existing conversion operational.
PiperOrigin-RevId: 257172216
This matches the result type of other functions returning c-string, and fixes a build failure where some compilers fail to construct the StringLiteral.
PiperOrigin-RevId: 257139513
Operations must only contain a single region. Once attached, all operations that contain a 'mlir::SymbolTable::getSymbolAttrName()' StringAttr attribute within the child region will be verified to ensure that the names are uniqued. Operations using this trait also gain access to the 'SymbolTable' class, which can be used to manage the symbol table of the operation. This class also provides constant-time lookup of symbols by name, and will automatically rename symbols on insertion.
PiperOrigin-RevId: 257123573
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
This is accomplished by adding a new callback to AbstractOperation that takes a ClassID for a given trait type and compares that against the ClassIDs for the traits used when registering an operation. This allows for opaquely querying if an operation was registered with a given trait, e.g:
Operation *op = ...;
bool singleResult = op->hasTrait<OpTrait::OneResult>();
PiperOrigin-RevId: 257007710
Now both functions and modules are just general ops and we do not require
top-level entities in a module's block to be the old builtin functions
any more. Removing the wrapping functions to simplify the tests.
PiperOrigin-RevId: 257003572
Address ClangTidy finding:
* std::move of the expression of the trivially-copyable type 'mlir::Module' (aka 'mlir::ModuleOp') has no effect; remove std::move()
PiperOrigin-RevId: 256981849
All non-static functions in LinalgOp::Model override pure virtual functions
from LinalgOp::Concept, but only some of them have the `override` specifier.
This may lead one to erroneously believe the functions without the specified
are not overrides or virtual functions. Add the specifier to all relevant
functions.
PiperOrigin-RevId: 256948453
River Riddle