| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Summary: Some data values have a different storage width than the corresponding MLIR type, e.g. bfloat is currently stored as a double.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D72478
|
|
|
|
|
|
| |
ValuePtr was a temporary typedef during the transition to a value-typed Value.
PiperOrigin-RevId: 286945714
|
|
|
|
| |
PiperOrigin-RevId: 286906740
|
|
|
|
|
|
|
|
|
|
| |
Value being value-typed.
This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ
This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.
PiperOrigin-RevId: 286844725
|
|
|
|
|
|
| |
The generated build methods have result type before the arguments (operands and attributes, which are also now adjacent in the explicit create method). This also results in changing the create method's ordering to match most build method's ordering.
PiperOrigin-RevId: 271755054
|
|
|
|
|
|
| |
The context can easily be recovered from the Location in these situations.
PiperOrigin-RevId: 265578574
|
|
|
|
|
|
|
| |
Use of std::isupper and std::islower need <cctype> header file. Fix
that and also fix the header of a file to match the file name.
PiperOrigin-RevId: 260816852
|
|
|
|
|
|
|
|
|
|
|
|
| |
All non-argument attributes specified for an operation are treated as
decorations on the result value and (de)serialized using OpDecorate
instruction. An error is generated if an attribute is not an argument,
and the name doesn't correspond to a Decoration enum. Name of the
attributes that represent decoerations are to be the snake-case-ified
version of the Decoration name.
Add utility methods to convert to snake-case and camel-case.
PiperOrigin-RevId: 260792638
|
|
|
|
|
|
| |
with <=15 values.
PiperOrigin-RevId: 253711372
|
|
|
|
|
|
| |
initializer_list.
PiperOrigin-RevId: 253234385
|
|
|
|
|
|
|
|
| |
Some compilers find initializer list constructors from boolean literals
ambiguous between ArrayRef<bool> and ArrayRef<Attribute>. Call the
ArrayRef<bool> constructor explicitly to disambiguate.
PiperOrigin-RevId: 253224859
|
|
|
|
|
|
| |
VectorType.
PiperOrigin-RevId: 253125435
|
|
|
|
|
|
| |
construction. This essentially means that we always auto-detect splat data and only store the minimum amount of data necessary. Support for parsing dense splats, and removing SplatElementsAttr(now that it is redundant) will come in followup cls
PiperOrigin-RevId: 252720561
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 249916947
|
|
|
|
|
|
|
|
|
|
|
| |
We now have sufficient extensibility in dialects to move attribute components
such as SDBM out of the core IR into a dedicated dialect and make them
optional. Introduce an SDBM dialect and move the code. This is a mostly
non-functional change.
--
PiperOrigin-RevId: 249244802
|
|
|
|
|
|
|
|
|
| |
A couple of warnings was produced when compiling this test due to comaprisons
with a signed literal. Used unsigned literals instead.
--
PiperOrigin-RevId: 249242970
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Affine expressions are designed as components of an attribute and are unique'd
in the MLIRContext. When affine expressions were implemented, uniqu'ing
objects in a context required to modify MLIRContext implementation. This is no
longer the case as generic StorageUniquer has been introduced. Port the
AffineExpr construction to use the new infrastructure by introducing an
affineUniquer into the MLIRContext.
--
PiperOrigin-RevId: 249207539
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SDBM has an output format representing the unterlying matrix and stripe
expressions. Move the SDBM tests from unit testing framework to
FileCheck-based tests, printing them to the standard output and using FileCheck
to test the output. Tests that check the API proper (e.g. that SDBM
expressions have a specific subtype) and that rely on non-syntatic properties
(equality of the set of constraints) are not ported.
--
PiperOrigin-RevId: 249006055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide an "unsafe" version of the overloaded arithmetic operators for SDBM
expressions. These operators expect the operands to be of the right SDBM
expression subtype and assert if they are not. They also perform simple
folding operations as well as some semantically correct operations that
construct an SDBM expression of a different subtype, e.g., a difference
expression if the RHS of an operator+ is a negated variable. These operators
are scoped in a namespace to allow for a future "safe" version of the operators
that propagates null expressions to denote the error state when expressions
have wrong subtypes.
--
PiperOrigin-RevId: 248704153
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement the storage class for striped difference-bound matrices (SDBM) as a
container with a difference bounds matrix and a list of stripe expressions. An
SDBM defines an integer set. Provide conversion mechanisms between lists of
SDBM expressions treated as equalities with zero or less-than-or-equal
inequalities with zero.
--
PiperOrigin-RevId: 248702871
|
|
|
|
|
|
|
|
|
|
| |
valid at runtime.
tensor<*xf32> could be a tensor<1xf32> at runtime but this verifyShapeMatch would return failure and say function is invalid.
--
PiperOrigin-RevId: 248583038
|
|
|
|
|
|
|
|
| |
This trait only works for tensor and vector types at the moment, verifying that the element type of an op with only tensor and vector types match. Added a unit test for it as there is no op currently in core that uses this trait.
--
PiperOrigin-RevId: 246661697
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since SDBM expressions are a subset of affine expressions, they can be
converted to affine expressions in a straightforward way. The inverse
conversion may fail when the affine expression is not an SDBM. Implement the
inverse convresion assuming affine expressions are simplified and
canonicalizied, detect subtractive and multiplicative forms of the stripe
operation.
--
PiperOrigin-RevId: 245494735
|
|
|
|
|
|
|
|
|
|
|
| |
Striped difference-bound matrix expressions are a subset of affine expressions
supporting low-complexity algorithms that can be useful for loop
transformations. This introduces the basic data data structures for building
such expressions and unique'ing them in a MLIRContext.
--
PiperOrigin-RevId: 245380206
|
|
|
|
|
|
|
|
| |
some comments to make it clear that 'name' refers to the dialect namespace.
--
PiperOrigin-RevId: 241103116
|
|
|
|
|
|
|
|
|
| |
* Add initial version of build files;
* Update README with instructions to download and build MLIR from github;
--
PiperOrigin-RevId: 241102092
|
|
|
|
|
|
|
|
| |
guarantee that the namespace of a dialect can be used a unique key.
--
PiperOrigin-RevId: 241049578
|
|
|
|
| |
PiperOrigin-RevId: 240777521
|
|
|
|
|
|
|
|
| |
usages of Instruction will still refer to a typedef in the interim.
This is step 1/N to renaming Instruction to Operation.
PiperOrigin-RevId: 240431520
|
|
from InstructionSupport.h.
PiperOrigin-RevId: 236911640
|