| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
PiperOrigin-RevId: 251988464
|
|
|
|
|
|
| |
weird build failures on MSVC related to typelist_contains for missing template arguments.
PiperOrigin-RevId: 251987621
|
|
|
|
|
|
|
|
| |
This function returns the element type of the underlying type or the input type itself. This removes some of the casting and code from ODS and into C++ code.
I've not converted all the call sites (as this requires a new include and target) and wanted to run it past folks first.
PiperOrigin-RevId: 251978156
|
|
|
|
| |
PiperOrigin-RevId: 251972430
|
|
|
|
| |
PiperOrigin-RevId: 251953766
|
|
|
|
|
|
| |
DenseFPElementsAttr in favor of just one DenseElementsAttr. Now that attribute has the ability to define 'classof(Attribute attr)' methods, these derived classes can just be specializations of the main attribute class.
PiperOrigin-RevId: 251948820
|
|
|
|
| |
PiperOrigin-RevId: 251945512
|
|
|
|
|
|
| |
8-bits. This removes the requirement that the underlying buffer be aligned to 64 bits which opens the door for several optimizations in the future, e.g. detecting splat.
PiperOrigin-RevId: 251944922
|
|
|
|
|
|
| |
dialects as opposed to individual operations. This allows for better support of unregistered operations, as well as removing the need to collect all of the operations for a given dialect(which may be very expensive).
PiperOrigin-RevId: 251943590
|
|
|
|
|
|
| |
drops the default "always succeed" match override to better align with RewritePattern.
PiperOrigin-RevId: 251941625
|
|
|
|
|
|
| |
all regions of a given operation are explicit capture only and will not reference values defined above the enclosing operation. This trait will be useful for applying some of the properties currently attached to Functions to operations, e.g. verifying dominance within a specific operation, enabling multi-threading of certain transformations between different instances, etc.
PiperOrigin-RevId: 251927466
|
|
|
|
|
|
| |
dominance information for any nested regions within the operation.
PiperOrigin-RevId: 251896520
|
|
|
|
| |
PiperOrigin-RevId: 251783931
|
|
|
|
|
|
| |
signature of the entry block.
PiperOrigin-RevId: 251759848
|
|
|
|
|
|
| |
functions about this parser and provides general parser support for operations, and regions of operations.
PiperOrigin-RevId: 251749622
|
|
|
|
|
|
| |
included by another include
PiperOrigin-RevId: 251725376
|
|
|
|
|
|
| |
comments, grouping similar functionality, and adding header blocks.
PiperOrigin-RevId: 251723883
|
|
|
|
|
|
| |
operation with a given OpBuilder and automatically try to fold it, similarly to OpBuilder::createOrFold. The difference here is that these methods enable folding to constants in addition to existing values. This functionality is then used to replace linalg::FunctionConstants.
PiperOrigin-RevId: 251716247
|
|
|
|
|
|
| |
the clang specific pragmas for ignoring field shadowing warnings.
PiperOrigin-RevId: 251712823
|
|
|
|
| |
PiperOrigin-RevId: 251712106
|
|
|
|
|
|
| |
and grouping related pieces of functionality.
PiperOrigin-RevId: 251688578
|
|
|
|
| |
PiperOrigin-RevId: 251681475
|
|
|
|
|
|
| |
operation after creating it. This can be used to remove operations that are likely to be trivially folded later. Note, these functions only fold operations if all of the folded results are existing values.
PiperOrigin-RevId: 251674299
|
|
|
|
|
|
| |
lowering identity(passthrough) operations to the same resultant type as the original operation.
PiperOrigin-RevId: 251665492
|
|
|
|
|
|
| |
any newly created value mappings.
PiperOrigin-RevId: 251658984
|
|
|
|
|
|
|
| |
* Add a getCurrentLocation that returns the location directly.
* Add parseOperandList/parseTrailingOperandList overloads without the required operand count.
PiperOrigin-RevId: 251585488
|
|
|
|
|
|
| |
Considered adding more placeholders to designate types in the replacement pattern, but convinced for now sticking to simpler approach. This should at least enable specifying constraints across operands/results/attributes and we can start getting rid of the special cases.
PiperOrigin-RevId: 251564893
|
|
|
|
|
|
| |
instead of a function.
PiperOrigin-RevId: 251563898
|
|
|
|
|
|
| |
results.
PiperOrigin-RevId: 251512700
|
|
|
|
|
|
|
|
|
|
| |
This CL adds SPV_ModuleEndOp for terminating the only block inside a
SPV_ModuleOp's only region. Verification now enforces a spv.module only
contains func or spv.* ops and no external or nested functions are
present. Because of the structural requirement of a block, spv.Return
is also added in this CL.
PiperOrigin-RevId: 251510706
|
|
|
|
|
|
| |
specific trait.
PiperOrigin-RevId: 251489498
|
|
|
|
| |
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
|
|
|
|
|
|
| |
when multi-threading is enabled.
PiperOrigin-RevId: 251478399
|
|
|
|
|
|
|
|
|
|
|
|
| |
argument attributes is the same as Function:
func @foo(i1 {dialect.attr: 10 : i64})
func @foo(%arg0: i1 {dialect.attr: 10 : i64}) {
return
}
PiperOrigin-RevId: 251473338
|
|
|
|
| |
PiperOrigin-RevId: 251417085
|
|
|
|
|
|
| |
Currently, we use different names for block and grid dimensions in the GPU vs. NVVM dialect, which is confusing. With this change, the NVVM names match the ones from the GPU dialect. The NVVM intrinsics use different names anyway, so it does not add new confusion.
PiperOrigin-RevId: 251389281
|
|
|
|
| |
PiperOrigin-RevId: 251333376
|
|
|
|
| |
PiperOrigin-RevId: 251314203
|
|
|
|
| |
PiperOrigin-RevId: 251306752
|
|
|
|
|
|
| |
Possible now because MemRef subclasses ShapedType
PiperOrigin-RevId: 251292951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 251287045
|
|
|
|
|
|
| |
functionality of 'Function', but with an operation. The pretty syntax for the operation is exactly the same as that of Function. This operation is currently builtin, but should hopefully be moved to a different dialect when it has been completely decoupled from IR/. This is the first patch in a large series that refactors Functions to be represented as operations.
PiperOrigin-RevId: 251281612
|
|
|
|
| |
PiperOrigin-RevId: 251269521
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regions at the same level of nesting to have values with the same SSA name. This is a necessary step for representing functions as operations.
The following is now valid IR:
foo.op ... {
%val = ...
}, {
%val = ...
}
PiperOrigin-RevId: 251249875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
* Fix a miscompile on older clang versions when initializing an ArrayRef with an unsigned variadic template argument.
* Update the errors to use the streaming interface instead of Twine.
PiperOrigin-RevId: 251223929
|
|
|
|
|
|
| |
improve readability.
PiperOrigin-RevId: 251158192
|