| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Now that modules are also operations, nothing prevents one from defining SSA
values in the module. Doing so in an implicit top-level module, i.e. outside
of a `module` operation, was leading to a crash because the implicit module was
not associated with an SSA name scope. Create a name scope before parsing the
top-level module to fix this.
PiperOrigin-RevId: 262366891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the recently introduced support for hexadecimal float literals to tensor
literals, which may also contain special floating point values such as
infinities and NaNs.
Modify TensorLiteralParser to store the list of tokens representing values
until the type is parsed instead of trying to guess the tensor element type
from the token kinds (hexadecimal values can be either integers or floats, and
can be mixed with both). Maintain the error reports as close as possible to
the existing implementation to avoid disturbing the tests. They can be
improved in a separate clean-up if deemed necessary.
PiperOrigin-RevId: 260794716
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- introduce parseRegionArgumentList (similar to parseOperandList) to parse a
list of region arguments with a delimiter
- allows defining custom parse for op's with multiple/variadic number of
region arguments
- use this on the gpu.launch op (although the latter has a fixed number
of region arguments)
- add a test dialect op to test region argument list parsing (with the
no delimiter case)
Signed-off-by: Uday Bondhugula <uday@polymagelabs.com>
Closes tensorflow/mlir#40
PiperOrigin-RevId: 259442536
|
|
|
|
|
|
| |
Fixes tensorflow/mlir#51
PiperOrigin-RevId: 259415034
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Module is a legacy name that only exists as a typedef of ModuleOp.
PiperOrigin-RevId: 257427248
|
|
|
|
|
|
| |
This allows for giving a Module a more interesting location than 'Unknown'.
PiperOrigin-RevId: 257310117
|
|
|
|
| |
PiperOrigin-RevId: 256995548
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
affine.load/store/dma_start/dma_wait.
In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands).
Significant code changes occur here:
*) Vectorization: LoopAnalysis.cpp, Vectorize.cpp
*) Affine Transforms: Transforms/Utils/Utils.cpp
PiperOrigin-RevId: 256395088
|
|
|
|
|
|
| |
As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types.
PiperOrigin-RevId: 256246112
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
about the buffer size. This is needed to resolve the operand
correctly. Add that information to view op
serialization/deserialization
Also modify the parsing of buffer type by splitting at 'x' to
side-step issues with StringRef number parsing.
PiperOrigin-RevId: 256188319
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This functionality is now moved to a new class, ModuleManager. This class allows for inserting functions into a module, and will auto-rename them on insert to ensure a unique name. This now means that users adding new functions to a module must ensure that the function name is unique, as the Module will no longer do it automatically. This also means that Module::getNamedFunction now operates in O(N) instead of the O(c) time it did before. This simplifies the move of Modules to Operations as the ModuleOp will not be able to have this functionality.
PiperOrigin-RevId: 255846088
|
|
|
|
| |
PiperOrigin-RevId: 255532918
|
|
|
|
| |
PiperOrigin-RevId: 255505300
|
|
|
|
|
|
| |
Some dialects allow for string types, and this allows for reusing StringAttr for constants of these types.
PiperOrigin-RevId: 255413948
|
|
|
|
| |
PiperOrigin-RevId: 255316118
|
|
|
|
|
|
|
|
| |
Split out class to command line parser for translate methods into standalone
class. Similar to splitting up mlir-opt to reuse functionality with different
initialization.
PiperOrigin-RevId: 255225790
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Values (NFC)
The error would look like:
path/filename.mlir:32:23: error: use of value '%28' expects different type than prior uses: ''i32'' vs ''!_tf.control''
PiperOrigin-RevId: 254874859
|
|
|
|
|
|
| |
operands being None, Volatile, Aligned and Nontemporal
PiperOrigin-RevId: 254792353
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
behavior of InFlightDiagnostic and enables notes to be converted to failure.
PiperOrigin-RevId: 254579098
|
|
|
|
|
|
| |
Now that Locations are Attributes they contain a direct reference to the MLIRContext, i.e. the context can be directly accessed from the given location instead of being explicitly passed in.
PiperOrigin-RevId: 254568329
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
a historical dependency that is no longer needed.
PiperOrigin-RevId: 254460518
|
|
|
|
| |
PiperOrigin-RevId: 254349019
|
|
|
|
|
|
| |
Identifier already contains all of the necessary functionality/verification, so having a separate class for filenames is unnecessary.
PiperOrigin-RevId: 253855505
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
'parseFloatAttr'. The invariants of FloatAttr are already checked before construction. This also removes an unnecessary materialization of a mlir::Location which becomes expensive when parsing dense element literals.
PiperOrigin-RevId: 252545776
|
|
|
|
|
|
|
|
|
|
|
| |
This CL exposes a parseType method which allows standalone reuse of the MLIR type parsing mechanism. This is a free function for now because the underlying MLIR parser is not guaranteed to receive a StringRef which lives in the proper MemBuffer. This requires building a new MemBuffer/SourceMgr and modifying the Parser constructor to not require an mlir::Module.
The error diagnostic emitted by parseType has context limited to the local string.
For now the dialect has the additional option to emit its own extra error that has the FileLineColLoc context.
In the future, both error messages should be combined into a single error.
PiperOrigin-RevId: 252468911
|
|
|
|
| |
PiperOrigin-RevId: 251945512
|
|
|
|
|
|
| |
functions about this parser and provides general parser support for operations, and regions of operations.
PiperOrigin-RevId: 251749622
|
|
|
|
|
|
| |
comments, grouping similar functionality, and adding header blocks.
PiperOrigin-RevId: 251723883
|
|
|
|
|
|
| |
the clang specific pragmas for ignoring field shadowing warnings.
PiperOrigin-RevId: 251712823
|
|
|
|
|
|
| |
and grouping related pieces of functionality.
PiperOrigin-RevId: 251688578
|
|
|
|
|
|
|
| |
* Add a getCurrentLocation that returns the location directly.
* Add parseOperandList/parseTrailingOperandList overloads without the required operand count.
PiperOrigin-RevId: 251585488
|
|
|
|
|
|
| |
instead of a function.
PiperOrigin-RevId: 251563898
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|