| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MLIR does not have support for parsing special floating point values such as
infinities and NaNs. If programmatically constructed, these values are printed
as NaN and (+-)Inf and cannot be parsed back. Add parser support for
hexadecimal literals in float attributes, following LLVM IR. The literal
corresponds to the in-memory representation of the floating point value.
IEEE 754 defines a range of possible values for NaNs, storing the bitwise
representation allows MLIR to properly roundtrip NaNs with different bit values
of significands.
The initial version of this commit was missing support for float literals that
used to be printed in decimal notation as a fallback, but ended up being
printed in hexadecimal format which became the fallback for special values.
The decimal fallback behavior was not exercised by tests. It is currently
reinstated and tested by the newly added test @f32_potential_precision_loss in
parser.mlir.
PiperOrigin-RevId: 260790900
|
|
|
|
| |
PiperOrigin-RevId: 260037115
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MLIR does not have support for parsing special floating point values such as
infinities and NaNs. If programmatically constructed, these values are printed
as NaN and (+-)Inf and cannot be parsed back. Add parser support for
hexadecimal literals in float attributes, following LLVM IR. The literal
corresponds to the in-memory representation of the floating point value.
IEEE 754 defines a range of possible values for NaNs, storing the bitwise
representation allows MLIR to properly roundtrip NaNs with different bit values
of significands.
PiperOrigin-RevId: 260018802
|
|
|
|
|
|
|
| |
We already parse boolean "true"/"false" as ElementsAttr elements.
This CL makes it round-trippable that we are printing the same way.
PiperOrigin-RevId: 258784962
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 256995548
|
|
|
|
| |
PiperOrigin-RevId: 256579717
|
|
|
|
|
|
| |
This is an important step in allowing for the top-level of the IR to be extensible. FuncOp and ModuleOp contain all of the necessary functionality, while using the existing operation infrastructure. As an interim step, many of the usages of Function and Module, including the name, will remain the same. In the future, many of these will be relaxed to allow for many different types of top-level operations to co-exist.
PiperOrigin-RevId: 256427100
|
|
|
|
|
|
| |
As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction.
PiperOrigin-RevId: 256196193
|
|
|
|
|
|
| |
Function.
PiperOrigin-RevId: 255988352
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Remove the ability to print an attribute without a type, but allow for attributes to elide the type under certain circumstances. This fixes a bug where attributes within ArrayAttr, and other collection attributes, would never print the type.
PiperOrigin-RevId: 255306974
|
|
|
|
|
|
|
|
|
|
|
| |
The current syntax separates the name and value with ':', but ':' is already overloaded by several other things(e.g. trailing types). This makes the syntax difficult to parse in some situtations:
Old:
"foo: 10 : i32"
New:
"foo = 10 : i32"
PiperOrigin-RevId: 255097928
|
|
|
|
|
|
|
|
|
| |
This is the standard syntax for types on operations, and is also already used by IntegerAttr and FloatAttr.
Example:
dense<5> : tensor<i32>
dense<[3]> : tensor<1xi32>
PiperOrigin-RevId: 255069157
|
|
|
|
| |
PiperOrigin-RevId: 254997746
|
|
|
|
|
|
|
| |
The new operations affine.load and affine.store will take composed affine maps by construction.
These operations will eventually replace load and store operations currently used in affine regions and operated on by affine transformation and analysis passes.
PiperOrigin-RevId: 254754048
|
|
|
|
|
|
| |
This will allow for locations to be used in the same contexts as attributes. Given that attributes are nullable types, the 'Location' class now represents a non-nullable wrapper around a 'LocationAttr'. This preserves the desired semantics we have for non-optional locations.
PiperOrigin-RevId: 254505278
|
|
|
|
|
|
| |
preparation for making the location classes attributes instead of separate IR types.
PiperOrigin-RevId: 253860058
|
|
|
|
|
|
| |
OpAsmPrinter (NFC)
PiperOrigin-RevId: 253674584
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
value. The syntax for this is the same as 0-D tensors:
dense<tensor<100x100x100xi32>, 10>
dense<tensor<1x1x1xi64>, -5>
PiperOrigin-RevId: 252907880
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
MemRefs have the same notion of shape, rank, and fixed element type. This allows us to reuse utilities based on shape for memref.
All dyn_cast and isa calls for ShapedType have been checked and either modified to explicitly check for vector or tensor, or confirmed to not depend on the result being a vector or tensor.
Discussion in https://groups.google.com/a/tensorflow.org/forum/#!topic/mlir/cHLoyfGu8y8
--
PiperOrigin-RevId: 250945184
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 250572818
|
|
|
|
|
|
|
|
| |
with usages of FunctionAttr.
--
PiperOrigin-RevId: 250555680
|
|
|
|
|
|
|
|
| |
operand->getType. This also simplifies some lingering usages of result->getType.
--
PiperOrigin-RevId: 249889174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 248797935
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
files. (NFC)
--
PiperOrigin-RevId: 248332674
|
|
|
|
|
|
|
|
| |
the awkward use of CallSiteLoc as a variable usage location.
--
PiperOrigin-RevId: 248014642
|
|
|
|
|
|
|
|
| |
enum to allow for dialects to define attribute kinds. The currently defined attributes kinds have now been moved to StandardAttributes.
--
PiperOrigin-RevId: 247988373
|
|
|
|
|
|
|
|
| |
Fix clang warnings
--
PiperOrigin-RevId: 247556495
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 247472005
|
|
|
|
|
|
|
|
| |
types. This has the added benefit of removing type redundancy from the pretty form. As a consequence, IntegerAttr/FloatAttr will now always print the type even if it is i64/f64.
--
PiperOrigin-RevId: 247295828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into more general support for attribute aliases.
`#` alias `=` attribute-value
This also allows for dialects to define aliases for attributes in the AsmPrinter. The printer supports two types of attribute aliases, 'direct' and 'kind'.
* Direct aliases are synonymous with the current support for type aliases, i.e. this maps an alias to a specific instance of an attribute.
// A direct alias ("foo_str") for the string attribute "foo".
#foo_str = "foo"
* Kind aliases generates unique names for all instances of a given attribute kind. The generated aliases are of the form: `alias[0-9]+`.
// A kind alias ("strattr") for all string attributes could generate.
#strattr0 = "foo"
#strattr1 = "bar"
...
#strattrN = "baz"
--
PiperOrigin-RevId: 246851916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic form of operations currently supports optional regions to be
located after the operation type. As we are going to add a type to each
region in a leading position in the region syntax, similarly to functions, it
becomes ambiguous to have regions immediately after the operation type. Put
regions between operands the optional list of successors in the generic
operation syntax and wrap them in parentheses. The effect on the exisitng IR
syntax is minimal since only three operations (`affine.for`, `affine.if` and
`gpu.kernel`) currently use regions.
--
PiperOrigin-RevId: 246787087
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 246614498
|
|
|
|
|
|
|
|
| |
OpAsmPrinter. These should go through attributes like most everything else.
--
PiperOrigin-RevId: 246589682
|
|
|
|
|
|
|
|
|
|
| |
none-type ::= `none`
The `none` type is a unit type, i.e. a type with exactly one possible value, where its value does not have a defined dynamic representation.
--
PiperOrigin-RevId: 245599248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A unit attribute is an attribute that represents a value of `unit` type. The
`unit` type allows only one value forming a singleton set. This attribute value
is used to represent attributes that only have meaning from their existence.
One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context
parameter. It could be represented as a boolean attribute(true or false), but a
value of false doesn't really bring any value. The parameter either is the
self/context or it isn't.
```mlir {.mlir}
// A unit attribute defined with the `unit` value specifier.
func @verbose_form(i1 {unitAttr : unit})
// A unit attribute can also be defined without the `unit` value specifier.
func @simple_form(i1 {unitAttr})
```
--
PiperOrigin-RevId: 245254045
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 244488612
|