| 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
|
|
|
|
| |
PiperOrigin-RevId: 286906740
|
|
|
|
|
|
|
|
| |
in `mlir` namespace.
Aside from being cleaner, this also makes the codebase more consistent.
PiperOrigin-RevId: 286206974
|
|
|
|
|
|
|
|
| |
simplify defining index-able ranges.
Many ranges want similar functionality from a range type(e.g. slice/drop_front/operator[]/etc.), so these classes provide a generic implementation that may be used by many different types of ranges. This removes some code duplication, and also empowers many of the existing range types in MLIR(e.g. result type ranges, operand ranges, ElementsAttr ranges, etc.). This change only updates RegionRange and ValueRange, more ranges will be updated in followup commits.
PiperOrigin-RevId: 284615679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
an optional location.
In some situations a diagnostic may optionally be emitted by the presence of a location, e.g. attribute and type verification. These situations currently require extra 'if(loc) emitError(...); return failure()' wrappers that make verification clunky. These new overloads take an optional location and a list of arguments to the diagnostic, and return a LogicalResult. We take the arguments directly and return LogicalResult instead of returning InFlightDiagnostic because we cannot create a valid diagnostic with a null location. This creates an awkward situation where a user may try to treat the, potentially null, diagnostic as a valid one and encounter crashes when attaching notes/etc. Below is an example of how these methods simplify some existing usages:
Before:
if (loc)
emitError(*loc, "this is my diagnostic with argument: ") << 5;
return failure();
After:
return emitOptionalError(loc, "this is my diagnostic with argument: ", 5);
PiperOrigin-RevId: 283853599
|
|
|
|
|
|
|
|
| |
linear scan.
The elements of a DictionaryAttr are guaranteed to be sorted by name, so we can use a more efficient lookup when searching for an attribute.
PiperOrigin-RevId: 280035488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows for adding additional nested references to a SymbolRefAttr to allow for further resolving a symbol if that symbol also defines a SymbolTable. If a referenced symbol also defines a symbol table, a nested reference can be used to refer to a symbol within that table. Nested references are printed after the main reference in the following form:
symbol-ref-attribute ::= symbol-ref-id (`::` symbol-ref-id)*
Example:
module @reference {
func @nested_reference()
}
my_reference_op @reference::@nested_reference
Given that SymbolRefAttr is now more general, the existing functionality centered around a single reference is moved to a derived class FlatSymbolRefAttr. Followup commits will add support to lookups, rauw, etc. for scoped references.
PiperOrigin-RevId: 279860501
|
|
|
|
| |
PiperOrigin-RevId: 272851237
|
|
|
|
|
|
| |
This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr.
PiperOrigin-RevId: 264968151
|
|
|
|
| |
PiperOrigin-RevId: 264672975
|
|
|
|
|
|
| |
This will allow iterating the values of a non-opaque ElementsAttr, with all of the types currently supported by DenseElementsAttr. This should help reduce the amount of specialization on DenseElementsAttr.
PiperOrigin-RevId: 264637293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tensorflow/mlir#58 fixed and exercised
verification of load/store ops using empty affine maps. Unfortunately,
it didn't exercise the creation of them. This PR addresses that aspect.
It removes the assumption of AffineMap having at least one result and
stores a pointer to MLIRContext as member of AffineMap.
* Add empty map support to affine.store + test
* Move MLIRContext to AffineMapStorage
Closes tensorflow/mlir#74
PiperOrigin-RevId: 264416260
|
|
|
|
|
|
| |
All 'getValue' variants now require that the index is valid, queryable via 'isValidIndex'. 'getSplatValue' now requires that the attribute is a proper splat. This allows for querying these methods on DenseElementAttr with all possible value types; e.g. float, int, APInt, etc. This also allows for removing unnecessary conversions to Attribute that really want the underlying value.
PiperOrigin-RevId: 263437337
|
|
|
|
|
|
| |
The current implementation only returns one element for the splat case, which often comes as a surprise; leading to subtle/confusing bugs. The new behavior will include an iterate over the full range of elements, as defined by the shaped type, by providing the splat value for each iterator index.
PiperOrigin-RevId: 262756780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SPIR-V has multiple constant instructions covering different
constant types:
* `OpConstantTrue` and `OpConstantFalse` for boolean constants
* `OpConstant` for scalar constants
* `OpConstantComposite` for composite constants
* `OpConstantNull` for null constants
* ...
We model them all with a single spv.constant op for uniformity
and friendliness to transformations. This does mean that when
doing (de)serialization, we need to poke spv.constant's type
to determine which SPIR-V binary instruction to use.
This CL only covers the case of bool and integer spv.constant.
The rest will follow.
PiperOrigin-RevId: 259311698
|
|
|
|
|
|
|
|
|
|
| |
This cl standardizes the printing of the type of dialect attributes to work the same as other attribute kinds. The type of dialect attributes will trail the dialect specific portion:
`#` dialect-namespace `<` attr-data `>` `:` type
The attribute parsing hooks on Dialect have been updated to take an optionally null expected type for the attribute. This matches the respective parseAttribute hooks in the OpAsmParser.
PiperOrigin-RevId: 258661298
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed).
PiperOrigin-RevId: 255983022
|
|
|
|
|
|
| |
Some dialects allow for string types, and this allows for reusing StringAttr for constants of these types.
PiperOrigin-RevId: 255413948
|
|
|
|
|
|
| |
This allows for iterating over the internal elements via an iterator_range of Attribute, and also allows for removing the final SmallVectorImpl based 'getValues' method.
PiperOrigin-RevId: 255309555
|
|
|
|
|
|
|
|
| |
into the mlir namespace.
Now that Locations are attributes, they have direct access to the MLIR context. This allows for simplifying error emission by removing unnecessary context lookups.
PiperOrigin-RevId: 255112791
|
|
|
|
|
|
| |
This iterator is useful for implementing random access iterators based upon an index and an object pointer. Moving it to STLExtras allows for reuse elsewhere throughout the codebase, e.g. simplifying the DenseElementsAttr iterators.
PiperOrigin-RevId: 255020377
|
|
|
|
|
|
| |
types(I1/I16/I32/etc.) when creating the MLIRContext. This allows for these symbols to be accessed without the need to perform any lookups/locking.
PiperOrigin-RevId: 254410080
|
|
|
|
|
|
| |
DenseElementsAttr.
PiperOrigin-RevId: 253910543
|
|
|
|
| |
PiperOrigin-RevId: 253894445
|
|
|
|
|
|
| |
being a separate Attribute type. DenseElementsAttr provides a better internal representation for splat values as well as better API for accessing elements.
PiperOrigin-RevId: 253138287
|
|
|
|
| |
PiperOrigin-RevId: 253124057
|
|
|
|
|
|
| |
return ranges as opposed to filling a SmallVector. This is much more efficient for the general case and allows for avoiding constructing APInt/APFloat/Attribute when possible.
PiperOrigin-RevId: 253092550
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
bit write/read functions to static functions in Attributes.cpp.
PiperOrigin-RevId: 252094145
|
|
|
|
|
|
|
|
|
| |
character buffer. This made assumptions about how DenseElementsAttr structured its internal storage, which may change in the future. To replace the existing use cases, a few utility methods have been added:
* 'get' methods that allow constructing from an ArrayRef of integer or floating point values.
* A 'reshape' method to allow for changing the shape without changing the underlying data.
PiperOrigin-RevId: 252067898
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 251048081
|
|
|
|
|
|
|
|
| |
to missing include)
--
PiperOrigin-RevId: 251000296
|
|
|
|
|
|
|
|
|
|
| |
We want to support 64-bit shapes (even when the compiler is on a 32-bit architecture). Using int64_t consistently allows us to sidestep the bugginess of unsigned arithmetic.
Still unsigned: kind, memory space, and bit width. The first two are basically enums. We could have a discussion about the last one, but it's basically just a very large enum as well and we're not doing any math on it, I think.
--
PiperOrigin-RevId: 250985791
|
|
|
|
|
|
|
|
|
|
|
| |
attribute, DictionaryAttr. This attribute maintains a sorted list of NamedAttributes. This will allow for operations/functions to maintain sub dictionaries of attributes.
The syntax is the same as top level attribute dictionaries:
{sub_dictionary: {fn: @someFn, boolAttr: true}}
--
PiperOrigin-RevId: 250898950
|
|
|
|
|
|
|
|
|
|
| |
tensors.
This is in preparation for making MemRef a subclass of ShapedType, but also UnrankedTensor should already be excluded.
--
PiperOrigin-RevId: 250580197
|
|
|
|
|
|
|
|
|
| |
attr. This supports both the SplatElementsAttr and DenseElementsAttr for both
float and integer inputs / outputs.
--
PiperOrigin-RevId: 249681056
|
|
|
|
| |
PiperOrigin-RevId: 249550805
|
|
|
|
|
|
|
|
|
| |
attr. This supports both the SplatElementsAttr and DenseElementsAttr for both
float and integer inputs / outputs.
--
PiperOrigin-RevId: 249538085
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
dialect reference.
--
PiperOrigin-RevId: 249467245
|
|
|
|
|
|
|
|
| |
respective FunctionAttr.
--
PiperOrigin-RevId: 249137558
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for making it also support/be a parent class of MemRefType. MemRefs have similar shape/rank/element semantics and it would be useful to be able to use these same utilities for them.
This CL should not change any semantics and only change variables, types, string literals, and comments. In follow-up CLs I will prepare all callers to handle MemRef types or remove their dependence on ShapedType.
Discussion/Rationale in https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/cHLoyfGu8y8
--
PiperOrigin-RevId: 248476449
|
|
|
|
|
|
|
|
|
|
|
|
| |
adds support for a pretty syntax for dialects attributes that is synonymous with the pretty syntax for dialect types. This cl also adds a new attribute 'OpaqueAttr' that allows for roundtripping attributes attached to unregistered dialects.
Dialect attributes have the following syntax:
dialect-attribute ::= `#` dialect-namespace `<` `"` attr-data `"` `>`
dialect-attribute ::= `#` alias-name pretty-dialect-sym-body?
--
PiperOrigin-RevId: 248344416
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248050178
|
|
|
|
|
|
|
|
| |
enum to allow for dialects to define attribute kinds. The currently defined attributes kinds have now been moved to StandardAttributes.
--
PiperOrigin-RevId: 247988373
|
|
|
|
|
|
|
|
| |
has been removed. The dependency was on the op casting methods, which have now moved out of Operation, used by the walker.
--
PiperOrigin-RevId: 247944666
|
|
|
|
|
|
|
|
| |
the final steps towards allowing dialects to define their own attributes, but there are still several things missing before this is fully supported(e.g. parsing/printing ).
--
PiperOrigin-RevId: 247684322
|