Continue the convergence between LLVM dialect and built-in types by using the
built-in vector type whenever possible, that is for fixed vectors of built-in
integers and built-in floats. LLVM dialect vector type is still in use for
pointers, less frequent floating point types that do not have a built-in
equivalent, and scalable vectors. However, the top-level `LLVMVectorType` class
has been removed in favor of free functions capable of inspecting both built-in
and LLVM dialect vector types: `LLVM::getVectorElementType`,
`LLVM::getNumVectorElements` and `LLVM::getFixedVectorType`. Additional work is
necessary to design an implemented the extensions to built-in types so as to
remove the `LLVMFixedVectorType` entirely.
Note that the default output format for the built-in vectors does not have
whitespace around the `x` separator, e.g., `vector<4xf32>` as opposed to the
LLVM dialect vector type format that does, e.g., `!llvm.vec<4 x fp128>`. This
required changing the FileCheck patterns in several tests.
Reviewed By: mehdi_amini, silvas
Differential Revision: https://reviews.llvm.org/D94405
getDynOperands behavior is commonly used in a number of passes. Refactored to
use a helper function and avoid code reuse.
Differential Revision: https://reviews.llvm.org/D94340
Based on the comments in lib/Parser/TypeParser.cpp on the
parseMemRefType and parseTensorType functions.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94262
This ensures the memref base + indices expression is well-formed
Reviewed By: ThomasRaoux, ftynse
Differential Revision: https://reviews.llvm.org/D94441
This reverts commit df86f15f0c.
The gcc-5 build was broken by this change:
mlir/tools/mlir-linalg-ods-gen/mlir-linalg-ods-gen.cpp:1275:77: required from here
/usr/include/c++/5/ext/new_allocator.h:120:4: error: no matching function for call to 'std::pair<const std::__cxx11::basic_string<char>, {anonymous}::TCParser::RegisteredAttr>::pair(llvm::StringRef&, {anonymous}::TCParser::RegisteredAttr'
* Registers a small set of sample dialects.
* NFC with respect to existing C-API symbols but some headers have been moved down a level to the Dialect/ sub-directory.
* Adds an additional entry point per dialect that is needed for dynamic discovery/loading.
* See discussion: https://llvm.discourse.group/t/dialects-and-the-c-api/2306/16
Differential Revision: https://reviews.llvm.org/D94370
* We've got significant missing features in order to use most of these effectively (i.e. custom builders, region-based builders).
* We presently also lack a mechanism for actually registering these dialects but they can be use with contexts that allow unregistered dialects for further prototyping.
Differential Revision: https://reviews.llvm.org/D94368
The type tablegen backend now has enough support to represent these types well enough, so we can now move them to be declaratively defined.
Differential Revision: https://reviews.llvm.org/D94275
This allows for specifying additional get/getChecked methods that should be generated on the type, and acts similarly to how OpBuilders work. TypeBuilders have two additional components though:
* InferredContextParam
- Bit indicating that the context parameter of a get method is inferred from one of the builder parameters
* checkedBody
- A code block representing the body of the equivalent getChecked method.
Differential Revision: https://reviews.llvm.org/D94274
This removes the need for OpDefinitionsGen to use raw tablegen API, and will also
simplify adding builders to TypeDefs as well.
Differential Revision: https://reviews.llvm.org/D94273
Lowering of async dialect uses a fixed type converter and therefore does not support lowering non-standard types.
This revision adds a structural conversion so that non-standard types in `!async.value`s can be lowered to LLVM before lowering the async dialect itself.
Reviewed By: ezhulenev
Differential Revision: https://reviews.llvm.org/D94404
This wasn't possible before because there was no support for affine expressions
as maps. Now that this support is available, provide the mechanism for
constructing maps with a layout and inspecting it.
Rework the `get` method on MemRefType in Python to avoid needing an explicit
memory space or layout map. Remove the `get_num_maps`, it is too low-level,
using the length of the now-avaiable pseudo-list of layout maps is more
pythonic.
Depends On D94297
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94302
Now that the bindings for AffineExpr have been added, add more bindings for
constructing and inspecting AffineMap that consists of AffineExprs.
Depends On D94225
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94297
This adds the Python bindings for AffineExpr and a couple of utility functions
to the C API. AffineExpr is a top-level context-owned object and is modeled
similarly to attributes and types. It is required, e.g., to build layout maps
of the built-in memref type.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94225
When fusing tensor_reshape ops with generic/indexed_Generic op, new
linalg.init_tensor operations were created for the `outs` of the fused
op. While correct (technically) it is better to just reshape the
original `outs` operands and rely on canonicalization of init_tensor
-> tensor_reshape to achieve the same effect.
Differential Revision: https://reviews.llvm.org/D93774
This allow more accurate modeling of the side effects and allow dead code
elimination to remove dead transfer ops.
Differential Revision: https://reviews.llvm.org/D94318
Linalg ops are perfect loop nests. When materializing the concrete
loop nest, the default order specified by the Linalg op's iterators
may not be the best for further CodeGen: targets frequently need
to plan the loop order in order to gain better data access. And
different targets can have different preferences. So there should
exist a way to control the order.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D91795
With this, now we can specify a list of attributes on named ops
generated from the spec. The format is defined as
```
attr-id ::= bare-id (`?`)?
attr-typedef ::= type (`[` `]`)?
attr-def ::= attr-id `:` attr-typedef
tc-attr-def ::= `attr` `(` attr-def-list `)`
tc-def ::= `def` bare-id
`(`tensor-def-list`)` `->` `(` tensor-def-list`)`
(tc-attr-def)?
```
For example,
```
ods_def<SomeCppOp>
def some_op(...) -> (...)
attr(
f32_attr: f32,
i32_attr: i32,
array_attr : f32[],
optional_attr? : f32
)
```
where `?` means optional attribute and `[]` means array type.
Reviewed By: hanchung, nicolasvasilache
Differential Revision: https://reviews.llvm.org/D94240
Do not cache gpu.async.token type so that the pass can be created before the GPU dialect is registered.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D94397
This commit adds support for (de-)serializing SpecConstantOpeation. One
thing worth noting is that during deserialization, we assign a fake ID to
enclosed ops inside SpecConstantOpeation. We need to do this in order
for deserialization logic to properly update ID to value map and to
later reference the created value from the sibling 'spv::YieldOp'.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D93591
This assertion is an old remnant from earlier days when only affine functions existed.
It is not the place of affine map composition to check whether orthogonal considerations
on what is allowed to be a symbol under the AffineScope trait.
mlir-opt supports many more test cases. All available dialects supported by latest mlir-opt should be coverted in the test case.
Reviewed By: aartbik, stephenneuendorffer, mehdi_amini
Differential Revision: https://reviews.llvm.org/D93821
This change makes the scatter/gather syntax more consistent with
the syntax of all the other memory operations in the Vector dialect
(order of types, use of [] for index, etc.). This will make the MLIR
code easier to read. In addition, the pass_thru parameter of the
gather has been made mandatory (there is very little benefit in
using the implicit "undefined" values).
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D94352
The dialect conversion framework was enhanced to handle type
conversion automatically. OpConversionPattern already contains
a pointer to the TypeConverter. There is no need to duplicate it
in a separate subclass. This removes the only reason for a
SPIRVOpLowering subclass. It adapts to use core infrastructure
and simplifies the code.
Also added a utility function to OpConversionPattern for getting
TypeConverter as a certain subclass.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D94080
Large integers are generated in Circt commonly which exceed 4kbits. This aligns the maximum bitwidth in MLIR and LLVM.
Reviewed By: rriddle, lattner, mehdi_amini
Differential Revision: https://reviews.llvm.org/D94116
Adding the ability to index the base address brings these operations closer
to the transfer read and write semantics (with lowering advantages), ensures
more consistent use in vector MLIR code (easier to read), and reduces the
amount of code duplication to lower memrefs into base addresses considerably
(making codegen less error-prone).
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D94278
This revision adds a new `initialize(MLIRContext *)` hook to passes that allows for them to initialize any heavy state before the first execution of the pass. A concrete use case of this is with patterns that rely on PDL, given that PDL is compiled at run time it is imperative that compilation results are cached as much as possible. The first use of this hook is in the Canonicalizer, which has the added benefit of reducing the number of expensive accesses to the context when collecting patterns.
Differential Revision: https://reviews.llvm.org/D93147
Use custom mlir runner init/destroy functions to safely init and destroy shared libraries loaded by the JitRunner.
This mechanism is ignored for Windows builds (for now) because init/destroy functions are not exported, and library unloading relies on static destructors.
Re-submit https://reviews.llvm.org/D94270 with a temporary workaround for windows
Differential Revision: https://reviews.llvm.org/D94312
Change the implementation of LinalgOp with TensorReshapeOp by
expansion to be more modular and easier to follow.
Differential Revision: https://reviews.llvm.org/D93748
The existing verification of reshape ops in linalg (linalg.reshape and
linalg.tensor_reshape) allows specification of illegal ops, where
- A dynamic dimension is expanded into multiple dynamic
dimensions. This is ill-specified.
- A static dimension is expanded into dynamic dimension or viceversa,
- The product of extents of the static dimensions in the expanded type
doesnt match the static dimension of the collapsed type.
Making all of these illegal. This also implies that some pessimization
in canonicalization due to incomplete semantics of the operation can
be dropped.
Differential Revision: https://reviews.llvm.org/D93724
Continue the convergence between LLVM dialect and built-in types by replacing
the bfloat, half, float and double LLVM dialect types with their built-in
counterparts. At the API level, this is a direct replacement. At the syntax
level, we change the keywords to `bf16`, `f16`, `f32` and `f64`, respectively,
to be compatible with the built-in type syntax. The old keywords can still be
parsed but produce a deprecation warning and will be eventually removed.
Depends On D94178
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94179
Use custom mlir runner init/destroy functions to safely init and destroy shared libraries loaded by the JitRunner.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94270
This patch adds an attribute `inclusive` which if present causes
the upperbound to be included in the loop iteration interval.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D94235
Instead of checking explicitly checking for whether an op is usalbe
inside a `SpecConstantOperationOP`, this commit adds a new trait to
filter such ops.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D94288
to the conversion of LLVM IR dialect. These attributes are used in FIR to
support the lowering of Fortran using target-specific calling conventions.
Add roundtrip tests.
Add changes per review comments/concerns.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D94052
Some Python bindings tests were using FileCheck to match parts of the
error description produced only in the debug compilation mode. Remove
these parts (but keep the main message) to ensure tests also pass when
running them in the release compilation mode.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94221
The LLVM dialect type system has been closed until now, i.e. did not support
types from other dialects inside containers. While this has had obvious
benefits of deriving from a common base class, it has led to some simple types
being almost identical with the built-in types, namely integer and floating
point types. This in turn has led to a lot of larger-scale complexity: simple
types must still be converted, numerous operations that correspond to LLVM IR
intrinsics are replicated to produce versions operating on either LLVM dialect
or built-in types leading to quasi-duplicate dialects, lowering to the LLVM
dialect is essentially required to be one-shot because of type conversion, etc.
In this light, it is reasonable to trade off some local complexity in the
internal implementation of LLVM dialect types for removing larger-scale system
complexity. Previous commits to the LLVM dialect type system have adapted the
API to support types from other dialects.
Replace LLVMIntegerType with the built-in IntegerType plus additional checks
that such types are signless (these are isolated in a utility function that
replaced `isa<LLVMType>` and in the parser). Temporarily keep the possibility
to parse `!llvm.i32` as a synonym for `i32`, but add a deprecation notice.
Reviewed By: mehdi_amini, silvas, antiagainst
Differential Revision: https://reviews.llvm.org/D94178
the conversion of LLVM IR dialect. These attributes are used in FIR to
support the lowering of Fortran using target-specific calling
conventions.
Add roundtrip tests. Add changes per review comments/concerns.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D94052
The original implementation of the OpenMP dialect to LLVM IR translation has
been relying on a stack of insertion points for delayed insertion of branch
instructions that correspond to terminator ops. This is an intrusive into
ModuleTranslation and makes the translation non-local. A recent addition of the
WsLoop translation exercised another approach where the parent op is
responsible for converting terminators of all blocks in its regions. Use this
approach for other OpenMP dialect operations with regions, remove the stack and
deduplicate the code for converting such regions.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D94086
The functions will be removed by January 20th.
All call sites within MLIR have been converted in previous changes.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D94191
A previous patch made Value::getType() be resilient to null values which was
considered to be too sweeping. This is a more targeted change which requires
deabstracting some templates.
A middle ground would be to make ValueTypeIterator be tolerant to null values.
Differential Revision: https://reviews.llvm.org/D93908
This allows for singleton types without an explicit parser/printer to simply use
the mnemonic as the assembly format, removing the need for these types to provide the parser/printer
fields.
Differential Revision: https://reviews.llvm.org/D94194
Add same hoisting transformation existing for transfer ops on buffers for
transfer_ops on tensor. The logic is significantly different so this is done as
a separate transformation and it is expect that user would know which
transformation to use based on the flow.
Differential Revision: https://reviews.llvm.org/D94115
This field is currently being used to mean "Fully resolved class name", which breaks the usage by TypeDefs. This revision prefixes the name with the dialect namespace when necessary.
Differential Revision: https://reviews.llvm.org/D94192
Right now constraint/predicate traits/etc. use their "description" field as a one line human readable string. This breaks the current convention, by which a "description" may be multi-line. This revision renames the "description" field in these cases to "summary" which matches what the string is actually used as. This also unbreaks the use of TypeDefs(and eventually AttrDefs) in conjunction with existing type constraint facilities like `Optional`.
Differential Revision: https://reviews.llvm.org/D94133
This commit adds a new trait that can be attached to ops that have
unsigned semantics.
TODO:
- Check if other places in code can use the new attribute (possibly in this patch).
- Add a similar `SignedOp` attribute (in a new patch).
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D94068
LLVM dialect type parsing and printing have been using a local stack object
forwarded between recursive functions responsible for parsing or printing
specific types. This stack is necessary to intercept (mutually) recursive
structure types and avoid inifinite recursion. This approach works only thanks
to the closedness of the LLVM dialect type system: types that don't belong to
the dialect are not allowed. Switch the approach to using a `thread_local`
stack inside the functions parsing the structure types. This makes the code
slightly cleaner by avoiding the need to pass the stack object around and, more
importantly, makes it possible to reconsider the closedness of the LLVM dialect
type system. As a nice side effect of this change, container LLVM dialect types
now support type aliases in their body (although it is currently impossible to
also use the alises when printing).
Depends On D93713
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93714
The passed in tool name is not used, causing the wrong tool name to be printed by the help text.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D94120
This was added without full specification like other generated methods.
This then leads to other downstream dialects failing to compile the
generated code when they are not in the mlir namespace.
Differential Revision: https://reviews.llvm.org/D94132
Nicolas changed the tensor abstraction so that every output has
its own shape definition. This simplifies the "inference" that
was used in the sparse compiler.
Reviewed By: penpornk
Differential Revision: https://reviews.llvm.org/D94119
If an operation defines an optional attribute (OptionalAttr or
UnitAttr), transformations may wish to remove these attributes while
maintaining invariants established by the operation. Currently, the only
way to do this is by calling `Operation::removeAttr("attrName")`, which
requires developers to know the exact name of the attribute used by
table-gen. Furthermore, if the attribute name changes, this won't be
detected at compile time. Instead, `removeAttr` would return an empty
attribute and no errors would be raised, unless the caller checks for
the returned value.
This patch adds table gen support for generating `remove<AttrName>Attr`
methods for OptionalAttributes defined by operations.
Implementation choice: to preserve camelCase for the method's name, the
first character of an attribute called `myAttr` is changed to upper case
in order to preserve the coding style, so the final method would be
called `removeMyAttr`.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93903
Remove unnecessary `&` from loop variables.
Fix warnings: "loop variable is always a copy because the range does not
return a reference".
```
[240/2862] Building CXX object tools/mlir/tools/mlir-tblgen/CMakeFiles/mlir-tblgen.dir/TypeDefGen.cpp.o
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:25: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
for (const TypeDef &typeDef : defs)
^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:50:10: note: use non-reference type 'mlir::tblgen::TypeDef'
for (const TypeDef &typeDef : defs)
^~~~~~~~~~~~~~~~~~~~~~~~
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:23: warning: loop variable 'typeDef' is always a copy because the range of type 'llvm::iterator_range<llvm::mapped_iterator<std::__1::__wrap_iter<llvm::Record **>, (lambda at llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:40:16), mlir::tblgen::TypeDef> >' does not return a reference [-Wrange-loop-analysis]
for (const TypeDef &typeDef : defs)
^
llvm-project/mlir/tools/mlir-tblgen/TypeDefGen.cpp:64:8: note: use non-reference type 'mlir::tblgen::TypeDef'
for (const TypeDef &typeDef : defs)
^~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
[1934/2862] Building CXX object tools...Files/toyc-ch4.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
for (const auto &name_value :
^
llvm-project/mlir/examples/toy/Ch4/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
for (const auto &name_value :
^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
[1940/2862] Building CXX object tools...Files/toyc-ch5.dir/mlir/MLIRGen.cpp.o
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:22: warning: loop variable 'name_value' is always a copy because the range of type 'detail::zippy<detail::zip_shortest, ArrayRef<unique_ptr<VariableExprAST, default_delete<VariableExprAST> > > &, MutableArrayRef<BlockArgument> >' does not return a reference [-Wrange-loop-analysis]
for (const auto &name_value :
^
llvm-project/mlir/examples/toy/Ch5/mlir/MLIRGen.cpp:139:10: note: use non-reference type 'std::__1::tuple<const std::__1::unique_ptr<toy::VariableExprAST, std::__1::default_delete<toy::VariableExprAST> > &, mlir::BlockArgument &>'
for (const auto &name_value :
^~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
```
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D94003
In the past, this was a missing test case and the fusion was not supported. It's
supported after the revisit of init_tensor in Linalg.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D94093
BEGIN_PUBLIC
[mlir] Remove LLVMType, LLVM dialect types now derive Type directly
This class has become a simple `isa` hook with no proper functionality.
Removing will allow us to eventually make the LLVM dialect type infrastructure
open, i.e., support non-LLVM types inside container types, which itself will
make the type conversion more progressive.
Introduce a call `LLVM::isCompatibleType` to be used instead of
`isa<LLVMType>`. For now, this is strictly equivalent.
END_PUBLIC
Depends On D93681
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93713
Enable querying shape function library ops from the module. Currently
supports singular or array of them (as long as array has all unique ops
in mappings). The preferred canonical form would have one library, but
given the invariant on the mapping, this can easily be achieved by a
simple merging pass.
Preferred the attribute approach vs naming convention as these could be
added in multiple different ways.
* Works in tandem with prototype packaging scripts here: https://github.com/stellaraccident/mlir-py-release
* The `mlir` top-level now differentiates between in-tree builds where all packages are co-located and distribution mode where all native components are under a top-level `_mlir_libs` package.
* Also fixes the generated dialect python installation again. Hopefully the last tweak.
* With this, I am able to install and generate archives with the above setup script on Linux. Archive size=31M with just host codegen and headers/shared-libraries. Will need more linker tweaks when wiring up the next dependent project.
Differential Revision: https://reviews.llvm.org/D93936
Add command line option to read the configuration dumped by the MLIR crash
reproducer and adds those to the other command line options parsed by mlir-opt.
Simple convenience that enables `mlir-opt --run-reproducer /tmp/repro.mlir`
instead of needing to copy&paste the configuration.
Differential Revision: https://reviews.llvm.org/D93924
OffsetSizeAndStrideOpInterface ops may have a varying number of operands before the first
offset operand. This revision adds a method that such ops much implement to properly specify
the position of the first offset operand.
Differential Revision: https://reviews.llvm.org/D93947
- Add `PyAffineMap` to wrap around `MlirAffineMap`.
- Add `mlirPythonAffineMapToCapsule` and `mlirPythonCapsuleToAffineMap` to interoperate with python capsule.
- Add and test some simple bindings of `PyAffineMap`.
Differential Revision: https://reviews.llvm.org/D93200
* When porting npcomp to use these bindings, I ran into enough patterns of collisions that I decided to be somewhat draconian about not polluting the namespace.
* With these changes all of the npcomp dialects generate and pass what tests we have.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93920
This fixes an incorrect fatal error in TableGen. This code probably comes
from before attributes were allowed to interleave with operands in ODS.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D93915
If a ComplexType's element type is buildable, then that ComplexType should be
buildable. This is accomplished by the introduction of a new ODS class called
`SameBuildabilityAs`. This can be used by other types that are conditionally
buildable.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93892
- Change FunctionLike::setAllArgAttrs() and setAllResultAttrs() to rebuild the new list of
function attributes locally and call setAttr() just once instead of calling
setArgAttr()/setResultAttrs() for each argument which incrementally build the
attribute dictionary and can end up creating a lot of unused DictionaryAttr's (which are
uniqued and nor garbage collected).
Differential Revision: https://reviews.llvm.org/D93870
The asmprinter would crash when dumping IR objects that had their
operands dropped. With this change, we now get this output, which
makes op->dump() style debugging more useful.
%5 = "firrtl.eq"(<<NULL>>, <<NULL>>) : (<<NULL TYPE>>, <<NULL TYPE>>) -> !firrtl.uint<1>
Previously the asmprinter would crash getting the types of the null operands.
Differential Revision: https://reviews.llvm.org/D93869
Implement Bug 46698, making ODS synthesize a getType() method that returns a
specific C++ class for OneResult methods where we know that class. This eliminates
a common source of casts in things like:
myOp.getType().cast<FIRRTLType>().getPassive()
because we know that myOp always returns a FIRRTLType. This also encourages
op authors to type their results more tightly (which is also good for
verification).
I chose to implement this by splitting the OneResult trait into itself plus a
OneTypedResult trait, given that many things are using `hasTrait<OneResult>`
to conditionalize various logic.
While this changes makes many many ops get more specific getType() results, it
is generally drop-in compatible with the previous behavior because 'x.cast<T>()'
is allowed when x is already known to be a T. The one exception to this is that
we need declarations of the types used by ops, which is why a couple headers
needed additional #includes.
I updated a few things in tree to remove the now-redundant `.cast<>`'s, but there
are probably many more than can be removed.
Differential Revision: https://reviews.llvm.org/D93790
1. Add new methods to Async runtime API to support yielding async values
2. Add lowering from `async.yield` with value payload to the new runtime API calls
`async.value` lowering requires that payload type is convertible to LLVM and supported by `llvm.mlir.cast` (DialectCast) operation.
Reviewed By: csigg
Differential Revision: https://reviews.llvm.org/D93592
Previously for each op we generate a separate serialization
method for it. Those serialization methods duplicate the logic
of parsing operands/results/attributes and such.
This commit creates a generic method and let suitable op-specific
serialization method to call into it.
wc -l SPIRVSerialization.inc: before 8304; after: 5597 (So -2707)
Reviewed By: hanchung, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D93535
Previously for each op we generate a separate deserialization
method for it. Those deserialization methods duplicate the logic
of parsing operands/results/attributes and such.
This commit creates a generic method and let suitable op-specific
deserialization method to call into it.
wc -l SPIRVSerialization.inc: before 13290; after: 8304 (So -4986)
Reviewed By: hanchung, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D93504
This commit renames various SPIR-V related conversion files for
consistency. It drops the "Convert" prefix to various files and
fixes various comment headers.
Reviewed By: hanchung, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D93489
Previously all SCF to SPIR-V conversion patterns were tested as
the -convert-gpu-to-spirv pass. That obscured the structure we
want. This commit fixed it.
Reviewed By: ThomasRaoux, hanchung
Differential Revision: https://reviews.llvm.org/D93488
Adds rewrite patterns to convert select+cmp instructions into clamp
instructions whenever possible. Support is added to convert:
- FOrdLessThan, FOrdLessThanEqual to GLSLFClampOp.
- SLessThan, SLessThanEqual to GLSLSClampOp.
- ULessThan, ULessThanEqual to GLSLUClampOp.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D93618
LLVMType contains numerous static constructors that were initially introduced
for API compatibility with LLVM. Most of these merely forward to arguments to
`SpecificType::get` (MLIR defines classes for all types, unlike LLVM IR), while
some introduce subtle semantics differences due to different modeling of MLIR
types (e.g., structs are not auto-renamed in case of conflicts). Furthermore,
these constructors don't match MLIR idioms and actively prevent us from making
the LLVM dialect type system more open. Remove them and use `SpecificType::get`
instead.
Depends On D93680
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93681
Introduce a translation of OpenMP workshare loop construct to LLVM IR. This is
a minimalist version to enable the pipeline and currently only supports static
loop schedule (default in the specification) on non-collapsed loops. Other
features will be added on per-need basis.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D92055
This was long overdue. Replace the outdated type syntax with the new syntax,
and update the description of how memref load/stores are handled to reflect the
latest changes in the implementation.
Reviewed By: herhut
Differential Revision: https://reviews.llvm.org/D93555
One common situation is to create a lot of IR at a well known location,
e.g. when doing a big rewrite from one dialect to another where you're expanding
ops out into lots of other ops.
For these sorts of situations, it is annoying to pass the location into
every create call. As we discused in a few threads on the forum, a way to help
with this is to produce a new sort of builder that holds a location and provides
it to each of the create<> calls automatically.
This patch implements an ImplicitLocOpBuilder class that does this. We've had
good experience with this in the CIRCT project, and it makes sense to upstream to
MLIR.
I picked a random pass to adopt it to show the impact, but I don't think there is
any particular need to force adopt it in the codebase.
Differential Revision: https://reviews.llvm.org/D93717
LLVMType contains multiple instance methods that were introduced initially for
compatibility with LLVM API. These methods boil down to `cast` followed by
type-specific call. Arguably, they are mostly used in an LLVM cast-follows-isa
anti-pattern. This doesn't connect nicely to the rest of the MLIR
infrastructure and actively prevents it from making the LLVM dialect type
system more open, e.g., reusing built-in types when appropriate. Remove such
instance methods and replaces their uses with apporpriate casts and methods on
derived classes. In some cases, the result may look slightly more verbose, but
most cases should actually use a stricter subtype of LLVMType anyway and avoid
the isa/cast.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D93680
This commit addresses the issue of lowering affine.for and
affine.parallel having return values. Relevant test cases are also
added.
Signed-off-by: Prateek Gupta <prateek@polymagelabs.com>
Differential Revision: https://reviews.llvm.org/D93090
This is a temporary fix until figuring out how to correct the forward
declare in mlir/include/mlir/Support/LLVM.h
Differential Revision: https://reviews.llvm.org/D93666
This patch adds documentation for the `mlir-spirv-cpu-runner`.
It provides an overview of applied transformations and passes, as
well as an example walk-through.
Some typos in the documentation have been fixed as well.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D93620
Extend unroll to support all element-wise ops and allow unrolling for ops with
vector operands of with the same shape as the destination but different element
type (like Cmp or Select).
Differential Revision: https://reviews.llvm.org/D93121
This revision drops init_tensor arguments from Linalg on tensors and instead uniformizes the output buffers and output tensors to be consistent.
This significantly simplifies the usage of Linalg on tensors and is a stepping stone for
its evolution towards a mixed tensor and shape abstraction discussed in https://llvm.discourse.group/t/linalg-and-shapes/2421/19.
Differential Revision: https://reviews.llvm.org/D93469
Transfer_ops can now work on both buffers and tensor. Right now, lowering of
the tensor case is not supported yet.
Differential Revision: https://reviews.llvm.org/D93500
This patch addresses two issues:
1. Not supported ops are updated to pick up the changes in the
SPIR-V dialect.
2. Conversion on `spv.ExecutionMode` is updated.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D91881
This class used to serve a few useful purposes:
* Allowed containing a null DictionaryAttr
* Provided some simple mutable API around a DictionaryAttr
The first of which is no longer an issue now that there is much better caching support for attributes in general, and a cache in the context for empty dictionaries. The second results in more trouble than it's worth because it mutates the internal dictionary on every action, leading to a potentially large number of dictionary copies. NamedAttrList is a much better alternative for the second use case, and should be modified as needed to better fit it's usage as a DictionaryAttrBuilder.
Differential Revision: https://reviews.llvm.org/D93442
Reductions in innermost loops become harder for the backend to disambiguate
after bufferization into memrefs, resulting in less efficient load-update-store
cycles. By scalarizing innermost reductions, the backend is more likely to assign
a register to perform the reduction (also prepares vectorization). Even though
we could scalarize reductions for more outer loops and while-loops as well,
currently scalarization is only done for chains of innermost for-loops, where
it matters most, to avoid complicating codegen unnecessary (viz. adding lots
of yield instructions).
This CL also refactors condition simplification into the merger class,
where it belongs, so that conditions are simplified only once per loop
nest and not repeatedly as was currently done. This CL also fixes a few
minor bugs, some layout issues, and comments.
Reviewed By: penpornk
Differential Revision: https://reviews.llvm.org/D93143
This operation is used to materialize a tensor of a particular
shape. The shape could be specified as a mix of static and dynamic
values.
The use of this operation is to be an `init` tensor for Linalg
structured operation on tensors where the bounds of the computation
depends on the shape of the output of the linalg operation. The result
of this operation will be used as the `init` tensor of such Linalg
operations. To note,
1) The values in the tensor materialized is not used. Any operation to
which this is an init tensor is expected to overwrite the entire
tensor.
2) The tensor is materialized only for the shape of the output and to
make the loop bounds depend only on operands of the structured
operation.
Based on (1) and (2) it is assumed that these operations eventually go
away since they are only used in `dim` operations that can be
canonicalized to make this operation dead. Such canonicalization are
added here too.
Differential Revision: https://reviews.llvm.org/D93374
This better matches the rest of the infrastructure, is much simpler, and makes it easier to move these types to being declaratively specified.
Differential Revision: https://reviews.llvm.org/D93432
This document was not updated after the LLVM dialect type system had been
reimplemented and was using an outdated syntax. Rewrite the part of the
document that concerns type conversion and prepare the ground for splitting it
into a document that explains how built-in types are converted and a separate
document that explains how standard types and functions are converted, which
will better correspond to the fact that built-in types do not belong to the
standard dialect.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D93486
Alex Zinenko