| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
any newly created value mappings.
PiperOrigin-RevId: 251658984
|
|
|
|
|
|
| |
instead of a function.
PiperOrigin-RevId: 251563898
|
|
|
|
| |
PiperOrigin-RevId: 251485843
|
|
|
|
|
|
|
|
|
|
| |
traversal helpers.
- added a typed walk to Block (matching the equivalent on Function)
- added token parsers (incl optional variants) for : and (
- added applyConversionPatterns that takes a list of functions to apply patterns to
PiperOrigin-RevId: 251481608
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversions. Multi-level conversions are those that require multiple patterns to be applied before an operation is completely legalized. This essentially means that conversion patterns do not have to directly generate legal operations, and may be chained together to produce legal code.
To accomplish this, moving forward users will need to provide a legalization target that defines what operations are legal for the conversion. A target can mark an operation as legal by providing a specific legalization action. The initial actions are:
* Legal
- This action signals that every instance of the given operation is legal,
i.e. any combination of attributes, operands, types, etc. is valid.
* Dynamic
- This action signals that only some instances of a given operation are legal. This
allows for defining fine-tune constraints, like say std.add is only legal when
operating on 32-bit integers.
An example target is shown below:
struct MyTarget : public ConversionTarget {
MyTarget(MLIRContext &ctx) : ConversionTarget(ctx) {
// All operations in the LLVM dialect are legal.
addLegalDialect<LLVMDialect>();
// std.constant op is always legal on this target.
addLegalOp<ConstantOp>();
// std.return op has dynamic legality constraints.
addDynamicallyLegalOp<ReturnOp>();
}
/// Implement the custom legalization handler to handle
/// std.return.
bool isLegal(Operation *op) override {
// Process the dynamic handling for a std.return op (and any others that were
// marked "dynamic").
...
}
};
PiperOrigin-RevId: 251289374
|
|
|
|
|
|
|
|
| |
more tests.
--
PiperOrigin-RevId: 250950703
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 250782165
|
|
|
|
|
|
|
|
|
|
|
|
| |
* the 'empty' method should be used to check for emptiness instead of 'size'
* using decl 'CapturableHandle' is unused
* redundant get() call on smart pointer
* using decl 'apply' is unused
* using decl 'ScopeGuard' is unused
--
PiperOrigin-RevId: 250623863
|
|
|
|
|
|
|
|
| |
raw_ostream.
--
PiperOrigin-RevId: 250619765
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 250572818
|
|
|
|
|
|
|
|
|
|
|
| |
*) Factors slice union computation out of LoopFusion into Analysis/Utils (where other iteration slice utilities exist).
*) Generalizes slice union computation to take the union of slices computed on all loads/stores pairs between source and destination loop nests.
*) Fixes a bug in FlatAffineConstraints::addSliceBounds where redundant constraints were added.
*) Takes care of a TODO to expose FlatAffineConstraints::mergeAndAlignIds as a public method.
--
PiperOrigin-RevId: 250561529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix Block::splitBlock and Block::eraseFromFunction that erronously assume
blocks belong to functions. They now belong to regions. When splitting, new
blocks should be created in the same region as the existing block. When
erasing a block, it should be removed from the region rather than from the
function body that transitively contains the region.
Also rename Block::eraseFromFunction to Block::erase for consistency with other
IR containers.
--
PiperOrigin-RevId: 250278272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lowering from the Affine dialect to the Standard dialect was originally
implemented as a standalone pass. However, it may be used by other passes
willing to lower away some of the affine constructs as a part of their
operation. Decouple the transformation functions from the pass infrastructure
and expose the entry point for the lowering.
Also update the lowering functions to use `LogicalResult` instead of bool for
return values.
--
PiperOrigin-RevId: 250229198
|
|
|
|
|
|
|
|
| |
construction. This simplifies building the conversion pattern list from multiple sources.
--
PiperOrigin-RevId: 249930583
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249901490
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249887371
|
|
|
|
|
|
|
|
|
|
| |
*) 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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249857277
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249678839
|
|
|
|
|
|
|
|
| |
DialectConversion class is only necessary for type signature changes(block arguments or function arguments). This isn't always desired when performing a dialect conversion. This allows for those conversions without this need to run per function instead of per module.
--
PiperOrigin-RevId: 249657549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of pointer. The one downside to this is that the function reference held by a FunctionAttr needs to be explicitly looked up from the parent module. This provides several benefits though:
* 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
|
|
|
|
|
|
|
|
| |
any cloning. This works by caching all of the requested pattern rewrite operations, e.g. replace operation, and only applying them on a completely successful conversion.
--
PiperOrigin-RevId: 249490306
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249124895
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
(until C++17)
--
PiperOrigin-RevId: 248990338
|
|
|
|
|
|
|
|
| |
DialectConversionPattern.
--
PiperOrigin-RevId: 248980810
|
|
|
|
|
|
|
|
|
|
| |
operate in-place, as opposed to incrementally constructing a new function. This is crucial to allowing the use of non type-conversion patterns(normal RewritePatterns) as part of the conversion process.
The converter now works by inserting fake producer operations when replacing the results of an existing operation with values of a different, now legal, type. These fake operations are guaranteed to never escape the converter.
--
PiperOrigin-RevId: 248969130
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248877752
|
|
|
|
|
|
|
|
| |
instead of Pattern. This simplifies the infrastructure a bit by being able to reuse PatternRewriter and the RewritePatternMatcher, but also starts to lay the groundwork for a more generalized legalization framework that can operate on DialectOpConversions as well as normal RewritePatterns.
--
PiperOrigin-RevId: 248836492
|
|
|
|
|
|
|
|
| |
FuncBuilder. This also updates the edsc::ScopedContext to use a single builder that saves/restores insertion points. This is necessary for using edscs within RewritePatterns.
--
PiperOrigin-RevId: 248812645
|
|
|
|
|
|
|
|
| |
This is necessary for allowing more complicated rewrites in the future that may do things like update the insertion point (e.g. for rewrites involving regions).
--
PiperOrigin-RevId: 248803153
|
|
|
|
|
|
|
|
| |
'fold'. This new unified fold hook will take constant attributes as operands, and may return an existing 'Value *' or a constant 'Attribute' when folding. This removes the awkward situation where a simple canonicalization like "sub(x,x)->0" had to be written as a canonicalization pattern as opposed to a fold.
--
PiperOrigin-RevId: 248582024
|
|
|
|
|
|
|
|
| |
files. (NFC)
--
PiperOrigin-RevId: 248332674
|
|
|
|
|
|
|
|
| |
These are only required in .h files to disambiguate between C and C++ header files.
--
PiperOrigin-RevId: 248219135
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248050178
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247991231
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247926512
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247789235
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247785983
|
|
|
|
|
|
|
|
| |
replace usages of Operation::dyn_cast with llvm::dyn_cast.
--
PiperOrigin-RevId: 247780086
|
|
|
|
| |
PiperOrigin-RevId: 247778691
|
|
|
|
|
|
|
|
| |
replace usages of Operation::dyn_cast with llvm::dyn_cast.
--
PiperOrigin-RevId: 247778391
|
|
|
|
|
|
|
|
|
|
|
|
| |
generates remarks for testing, it isn't itself a transformation.
While there, upgrade its diagnostic emission to use the streaming interface.
Prune some unnecessary #includes.
--
PiperOrigin-RevId: 247768062
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247762545
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247758075
|
|
|
|
|
|
|
|
| |
Fix a GCC warning
--
PiperOrigin-RevId: 247670176
|
|
|
|
|
|
|
|
| |
Fix gcc warning.
--
PiperOrigin-RevId: 247647114
|
|
|
|
|
|
|
|
|
|
| |
to read region.
Also cleaned up dma-generate.mlir a bit.
--
PiperOrigin-RevId: 247417358
|
|
|
|
|
|
|
|
|
|
|
|
| |
The string was referenced but not captured in the lambda, which causes
a failure when compiling with MSVC.
This issue was discovered by @loic-joly-sonarsource with a proposed fix
in https://github.com/tensorflow/mlir/pull/22.
--
PiperOrigin-RevId: 247085897
|