| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
As Functions/Modules becomes operations, these methods will conflict with the 'verify' hook already on derived operation types.
PiperOrigin-RevId: 256246112
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL uses the generic CopyOp to promote a subview (constructed during tiling) into a new buffer + copy by:
1. Creating a new buffer for the subview.
2. Taking a view into the buffer and copying into it.
3. Adapting the linalg op to operating on the view from point 2.
Tiling is extended with a boolean flag to enable promoting views (all or nothing for now).
More specifically, the current implementation creates a buffer that is always of the full size of the ranges of the subview. This produces a buffer whose size may be bigger
than the actual size of the `subView` at the boundaries and is related to the full/partial tile problem.
In practice, we introduce a `buffer`, a `fullLocalView` and a `partialLocalView` such that:
* `buffer` is always the size of the subview in the full tile case.
* `fullLocalView` is a dense contiguous view into that buffer.
* `partialLocalView` is a dense non-contiguous slice of `fullLocalView`
that corresponds to the size of `subView` and accounting for boundary
effects.
The point of the full tile buffer is that constant static tile sizes are
folded and result in a buffer type with statically known size and alignment
properties.
Padding is introduced on the boundary tiles with a `fill` op followed by a partial `copy` op.
These behaviors will be refined later, on a per-need basis.
PiperOrigin-RevId: 256237319
|
|
|
|
|
|
| |
supporting only Offset decorations
PiperOrigin-RevId: 256216704
|
|
|
|
|
|
|
|
| |
* Added comments
* Improved op creation
* Used LogicalResult where suitable
PiperOrigin-RevId: 256203068
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Close tensorflow/mlir#23
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
PiperOrigin-RevId: 256171145
|
|
|
|
| |
PiperOrigin-RevId: 256169019
|
|
|
|
|
|
|
|
|
|
|
|
| |
This saves us the excessive string conversions and comparisons in
verification and transformation and scopes them only to parsing
and printing, which are meant for I/O so string conversions should
be fine.
In order to do this, changed the custom assembly format of
spv.module regarding addressing model and memory model.
PiperOrigin-RevId: 256149856
|
|
|
|
|
|
| |
of std::function.
PiperOrigin-RevId: 256099638
|
|
|
|
|
|
|
|
|
| |
* 'walk' functionality.
* Method to set the location.
* 'dump'/'print' methods.
* Method to set the attributes.
PiperOrigin-RevId: 256097960
|
|
|
|
|
|
|
|
|
| |
StringAttr-backed enum attribute cases changed to allow explicit values,
But this assertion was not deleted.
Fixes https://github.com/tensorflow/mlir/issues/39
PiperOrigin-RevId: 256090793
|
|
|
|
|
|
|
|
| |
Update to follow enumerators naming style
https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
this also avoids the mach/boolean.h macros.
PiperOrigin-RevId: 256069831
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The GPU Launch operation may take constants as arguments, in particular
affine-to-GPU mapping pass automatically forwards potentially constant lower
bounds of loops into the kernel. Define a canonicalization pattern for
LaunchOp that recreates the constants inside the kernel region instead of
accepting them as kernel arguments. This is currently restricted to standard
constants but may be extended to other constant operations.
Also fix an off-by-one indexing bug in OperandStorage::eraseOperand.
PiperOrigin-RevId: 256035437
|
|
|
|
| |
PiperOrigin-RevId: 256029944
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
cast is elided properly.
PiperOrigin-RevId: 255979732
|
|
|
|
|
|
|
|
|
|
| |
Type conversion does not necessarily affect all types, some of them may remain
untouched. The type conversion tool from the dialect conversion framework will
unconditionally insert a temporary cast operation from the type to itself
anyway, and will try to materialize it to a real conversion operation if there
are remaining uses. Simply use the original value instead.
PiperOrigin-RevId: 255975450
|
|
|
|
|
|
|
|
| |
The RUN line was missing a call to FileCheck making the test always pass. Add
the call to FileCheck and temporarily disable one of the tests that does not
produce the expected result.
PiperOrigin-RevId: 255974805
|
|
|
|
| |
PiperOrigin-RevId: 255960171
|
|
|
|
|
|
| |
when there is an enumerant without explicit value
PiperOrigin-RevId: 255950779
|
|
|
|
|
|
| |
an enumerant without explicit value.
PiperOrigin-RevId: 255945801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ODS, right now we use StringAttrs to emulate enum attributes. It is
suboptimal if the op actually can and wants to store the enum as a
single integer value; we are paying extra cost on storing and comparing
the attribute value.
This CL introduces a new enum attribute subclass that are backed by
IntegerAttr. The downside with IntegerAttr-backed enum attributes is
that the assembly form now uses integer values, which is less obvious
than the StringAttr-backed ones. However, that can be remedied by
defining custom assembly form with the help of the conversion utility
functions generated via EnumsGen.
Choices are given to the dialect writers to decide which one to use for
their enum attributes.
PiperOrigin-RevId: 255935542
|
|
|
|
| |
PiperOrigin-RevId: 255908660
|
|
|
|
|
|
|
|
| |
Originally, AffineToGPUPass was created and registered in the source file
mainly for testing purposes. Provide a factory function that constructs
AffineToGPU pass to make it usable in pass pipelines.
PiperOrigin-RevId: 255902831
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This CL also fixes a parsing issue in the BufferType, adds LLVM lowering support for handling the static constant buffer size and a roundtrip test.
PiperOrigin-RevId: 255834356
|
| |
|
|
|
|
| |
PiperOrigin-RevId: 255700627
|
|\
| |
| |
| | |
PiperOrigin-RevId: 255694478
|
| |
| |
| | |
Co-Authored-By: Mehdi Amini <joker.eph@gmail.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
| |
maps for indexing memrefs by construction.
These ops are analogues of the current standard ops dma_start/wait, with the exception that the memref operands are affine expressions of loop IVs and symbols (analogous to affine.load/store).
The addition of these operations will enable changes to affine transformation and analysis passes which operate on memory dereferencing operations.
PiperOrigin-RevId: 255658382
|
|
|
|
| |
PiperOrigin-RevId: 255648303
|
|
|
|
|
|
|
|
| |
conversion must persist after the conversion has finished.
During conversion, if a type conversion has dangling uses a type conversion must persist after conversion has finished to maintain valid IR. In these cases, we now query the TypeConverter to materialize a conversion for us. This allows for the default case of a full conversion to continue working as expected, but also handle the degenerate cases more robustly.
PiperOrigin-RevId: 255637171
|
|
|
|
|
|
|
|
| |
constant then it is represented as <size x elementType>. If the size
is not a compile time constant, then it is represented as
<? x elementType>.
PiperOrigin-RevId: 255619400
|
|
|
|
| |
PiperOrigin-RevId: 255532918
|
|
|
|
| |
PiperOrigin-RevId: 255532863
|
|
|
|
| |
PiperOrigin-RevId: 255505300
|
|
|
|
|
|
|
|
| |
context.
This also adds a new 'Region::cloneInto' method that accepts an insertion position.
PiperOrigin-RevId: 255504640
|
|
|
|
| |
PiperOrigin-RevId: 255435454
|
|
|
|
|
|
| |
Some dialects allow for string types, and this allows for reusing StringAttr for constants of these types.
PiperOrigin-RevId: 255413948
|
|
|
|
|
|
| |
Addresses compiler warning.
PiperOrigin-RevId: 255407691
|
|
|
|
| |
PiperOrigin-RevId: 255316118
|
|
|
|
|
|
| |
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
|