Confined -> ConfinedAttr
AllAttrConstraintsOf -> AllOfAttr
To be in line with ConfinedType and AllOfType.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131822
This patch deprecates hasValue and getValue for consistency with
std::optional and llvm::Optional. Note that I've migrated all known
uses of them to has_value and value, respectively.
Differential Revision: https://reviews.llvm.org/D131366
An optional attribute dictionary before a region in an assembly format
is a potential format ambiguity because they both start with `{`.
Fixes#53077
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131636
This patch adds support for string literals as `custom` directive
arguments. This can be useful for re-using custom parsers and printers
when arguments have a known value. For example:
```
ParseResult parseTypedAttr(AsmParser &parser, Attribute &attr, Type type) {
return parser.parseAttribute(attr, type);
}
void printTypedAttr(AsmPrinter &printer, Attribute attr, Type type) {
return parser.printAttributeWithoutType(attr);
}
```
And in TableGen:
```
def FooOp : ... {
let arguments = (ins AnyAttr:$a);
let assemblyFormat = [{ custom<TypedAttr>($a, "$_builder.getI1Type()")
attr-dict }];
}
def BarOp : ... {
let arguments = (ins AnyAttr:$a);
let assemblyFormat = [{ custom<TypedAttr>($a, "$_builder.getIndexType()")
attr-dict }];
}
```
Instead of writing two separate sets of custom parsers and printers.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131603
This reland includes changes to the Python bindings.
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131801
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D131803
ReluN has been removed from the TOSA specification. It can be replaced
in all instances with Clamp(0,N)
Signed-off-by: Eric Kunze <eric.kunze@arm.com>
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D128683
`AllOfType` is a type constraint that satisfies all given type
constraints and `ConfinedType` is a type that satisfies additional
predicates. These shorthands simplify type constraint definition mostly
by removing the need to deal with `myType.predicate` manipulation.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D131788
The end-to-end test for this new feature also exposed a bug
in LLVM IR lowering (since then, fixed), where we need to account
for the min-poison bit as extra argument.
declare i32 @llvm.abs.i32(i32 <src>, i1 <is_int_min_poison>)
Reviewed By: bixia
Differential Revision: https://reviews.llvm.org/D131712
The LLVM intrinsic has a bool flag `is_int_min_poison` that needs to be
set.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D131785
Introduce two different failure propagation mode in the Transform
dialect's Sequence operation. These modes specify whether silenceable
errors produced by nested ops are immediately propagated, thus stopping
the sequence, or suppressed. The latter is useful in end-to-end
transform application scenarios where the user cannot correct the
transformation, but it is robust enough to silenceable failures. It
can be combined with the "alternatives" operation. There is
intentionally no default value to avoid favoring one mode over the
other.
Downstreams can update their tests using:
S='s/sequence \(%.*\) {/sequence \1 failures(propagate) {/'
T='s/sequence {/sequence failures(propagate) {/'
git grep -l transform.sequence | xargs sed -i -e "$S"
git grep -l transform.sequence | xargs sed -i -e "$T"
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D131774
MemRefUtils.h uses UINT_MAX, which is not included in current header files list. This patch include climits to avoid compilation error in this header file.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131529
Using a loop init_arg inside of the loop is not supported. This change adds a pre-processing pass that resolves such IR with copies.
Differential Revision: https://reviews.llvm.org/D131689
This removes the type from EmitC's opaque attribute. The value provided
as a StringRefParameter can always be emitted as is. In consquence the
constant and variable ops explicitly need to opaque attributes which are
no longer typed attributes.
Co-authored-by: Simon Camphausen <simon.camphausen@iml.fraunhofer.de>
Reviewed By: Mogball, jpienaar
Differential Revision: https://reviews.llvm.org/D131666
Switch variadic operand and result segment size attributes to use the
dense i32 array. Dense integer arrays were introduced primarily to
represent index lists. They are a better fit for segment sizes than
dense elements attrs.
Depends on D131738
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D131702
Follow-up to D123774, where the syntax of dense arrays was discussed. It
was included that the syntax should be changed to `array<i32: 1, 2>`.
This patch changes the syntax but importantly preserves the `[1, 2]`
syntax when embedding these attributes in assembly formats through ODS.
Reviewed By: mehdi_amini, jpienaar
Differential Revision: https://reviews.llvm.org/D131738
Fix hasNoInterveningEffect in the presence of ops from different affine
scopes. Also, correctly check for dependence failures as well instead of
just for the existence of a dependence.
Differential Revision: https://reviews.llvm.org/D131641
This sets the `MLIR_PDLL_TABLEGEN_EXE` and `MLIR_PDLL_TABLEGEN_TARGET`
as cache variables which is necessary for cross-compiling projects that
rely on MLIR and the mlir-pdll-tblgen tool.
The patch is similar to https://reviews.llvm.org/D130350.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D131596
c7ec6e19d5 made LLVM adhere to the x86
psABI and pass bf16 in SSE registers instead of GPRs. This breaks the
custom versions of runtime functions we have for bf16 conversion. A
great fix for this would be to use __bf16 types instead which carry the
right ABI, but that type isn't widely available.
Instead just pretend it's a 32 bit float on the ABI boundary and
carefully cast it to the right type.
Fixes#57042
Refactor affine analysis helpers: the existing ones were using
unnecessary or improperly named arguments. NFC.
Differential Revision: https://reviews.llvm.org/D131557
Add missing check in affine dependence analysis when dependence analysis
isn't possible due to the ops being in different affine scopes. The
lack of such a check could lead to a crash or incorrect behavior in
several dependent utilities.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131556
Made passes converting ops from other dialects to spirv OperationPass,
so that downstream compiler could put them in a proper nested pass
manager to lower device code only.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D131591
The operation computes pow(b, p), where 'b' and 'p' are signed integers
of the same width. The result's type matches the operands' type.
Differential Revision: https://reviews.llvm.org/D129809
This patch "modernizes" the LLVM `insertvalue` and `extractvalue`
operations to use DenseI64ArrayAttr, since they only require an array of
indices and previously there was confusion about whether to use i32 or
i64 arrays, and to use assembly format.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131537
This change separates computation of the actual parameters of the subset and
the materialization of subview/extract_slice. That way the users can still use
Linalg tiling logic even if they use different operations to materialize the
subsets.
Differential Revision: https://reviews.llvm.org/D131053
When emitting the declarations for interface methods defined in ODS,
also emit their descriptions as C++ comments. This makes the
documentation accessible to C++ tooling such as IDEs that offers better
usability than reading it form the .td or the website.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D130478
Flang was not able to convert simd directive which contains nested
Fortran loops. The nested Fortran loops inside SIMD directive
are modelled as FIR loops and they need to be translated into LLVM
MLIR dialect.
Differential Revision: https://reviews.llvm.org/D131402
Reviewed by: peixin
Signed-off-by: Dominik Adamski <dominik.adamski@amd.com>
Previously, calling `Value.owner()` would C++ assert in debug builds if
`Value` was a block argument. Additionally, the behavior was just wrong
in release builds. This patch adds support for BlockArg Values.
This patch cleans up the definition of `DenseArrayAttrBase` by relying
more on ODS-generated methods. It also exposes an API for using the raw
data of a dense array, similar to `DenseIntOrFPElementsAttr::getRaw`.
Reviewed By: lattner, mehdi_amini
Differential Revision: https://reviews.llvm.org/D131450
They appeared at the wrong place in the switch, treating
them as unary op rather than binary op.
Reviewed By: bixia
Differential Revision: https://reviews.llvm.org/D131509
This makes it easier to use as a utility function to query the
mappings, including the reverse.
This commit also drops some storage classes that aren't needed
for now.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131411
This commit moves MemRef memory space to SPIR-V storage class
conversion out of the main SPIR-V type converter. Now the mapping
should happen as a prelimiary step before performing the final
conversion to SPIR-V. Flows are expect to write their own memory
space mappings like the `MapMemRefStorageClassPass` to handle
memory space mappings according to their needs.
This is needed because SPIR-V is serving multiple client APIs,
including Vulkan and OpenCL. Different client APIs might want
to use different storage classes for buffers in a particular
memory space, e.g., `StorageBuffer` for Vulkan vs. `CrossWorkgroup`
for OpenCL when converting the default 0 memory space. Hardcoding
a specific mapping makes that hard. While it's possible to embed
selection logic further inside the main type converter, it will
make the main type converter even complicated. So it's better to
separate the concerns, as mapping the memory space is really
concretizing the meaning of those numeric memory spaces in the
particular context of SPIR-V lowering.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131410
* Avoid restricting the pass to to builtin module ops. The pass
should be able to run on any region ops.
* Avoid hardcoding func FuncOp when handling functions. Instead,
use the function op interface.
* Assigns the default mapping in the constructor. So for cases
where we are using the pass in a pipeline, we still have a
meaningful default.
Along the way, dropped uncessary unrealized conversion casts and
use full conversion. The pass should be able to convert all sorts
of ops; there is really no need to have such bridages.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131409
In addition to memref, accept ranked tensor as the base operand of vector.gather, similar to vector.trasnfer_read.
This will allow us to vectorize noncontiguous tensor.extract into vector.gather. Full discussion can be found here: https://github.com/iree-org/iree/issues/9198
Reviewed By: hanchung, dcaballe
Differential Revision: https://reviews.llvm.org/D130097
Previously we can only lower arith.index_cast with 1-D vectors to LLVM. This change added the support for n-D vectors.
Reviewed By: ftynse, hanchung
Differential Revision: https://reviews.llvm.org/D129907
Previously we are using IntegerAttr to back all SPIR-V enum
attributes. Therefore we all such attributes are showed like
IntegerAttr in IRs, which is barely readable and breaks
roundtripability of the IR. This commit changes to use
`EnumAttr` as the base directly so that we can have separate
attribute definitions and better IR printing.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131311
Resolve almost all clang tidy warnings in this file:
1. Clean up string constants.
2. Use consistent argument names across function declarations and definitions. Rename `state` - > `result`, which is consistent with the other dialects.
3. Remove misleading function parameter name comments (`argTypes`). This did not match the actual function argument (`bool enableNameShadowing`).
4. Simplify calls to `is_splat`.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D131297
now that `arith` dialect has maxf/minf use it instead of cmp/select.
Also refactor clamp helpers to make them simlper.
Reviewed By: rsuderman
Differential Revision: https://reviews.llvm.org/D131426
The test was using a missing prefix. Add the prefix and fix the naming.
Found by @csigg
Reviewed By: csigg
Differential Revision: https://reviews.llvm.org/D131428
Moved some parts from comments (not user facing) to the actual description
(user facing). Rephrased a bit as well.
Reviewed By: Peiming
Differential Revision: https://reviews.llvm.org/D131418
This further relaxes the requirement to allow aliased resources
to have different primitive types and some are scalars while the
other are vectors.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D131207
Currently, dense tensors are initialized in Sparse Integration tests using
"buffer.tensor_alloc and scf.for" . This makes code harder to read and maintain.
This diff uses tensor.generate instead to initialize dense tensors.
Testing: Ran integration tests after building with -DLLVM_USE_SANITIZER=Address flag.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D131404
This commit updates all SPIR-V enum definitions to match the latest
specification (v1.6 revision 2). Along the way, fixed some issues
in `gen_spirv_dialect.py` and added a new script for refreshing
all op definitions for such cases.
Reviewed By: kuhar
Differential Revision: https://reviews.llvm.org/D131293
Adds an integer absolute value op to the math dialect.
When converting to LLVM, this op is lowered to the LLVM `abs` intrinsic.
When converting to SPIRV, this op is lowered to `spv.GL.SAbs`.
Depends on D131325
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131327
IntegerPolyhedron::findIntegerLexmin currently does not return values of
the local ids, so when a test for sampling includes a set with locals, the
result of findIntegerLexmin should be checked using containsPointNoLocal,
not containsPoint.
Prior to this patch, the `add_tablegen()` macro in
llvm/cmake/modules/TableGen.cmake added the install rule only if
`project` matched `LLVM` or `MLIR`. This patch adds an optional
`DESTINATION` argument, which, if non-empty, decides whether (and where)
to install the tablegen tool, thus eliminating the need for
project-specific overrides. This patch also updates all other
invocations of the `add_tablegen()` macro.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D131282
This patch fixes:
llvm-project/mlir/include/mlir/IR/OpDefinition.h:1544:19: error: use
of bitwise '|' with boolean operands
[-Werror,-Wbitwise-instead-of-logical]
Now that C++17 is enabled in LLVM, a lot of the TODOs and patterns to emulate C++17 features can be eliminated.
The steps I have taken were essentially:
```
git grep C++17
git grep c++17
git grep "initializer_list<int>"
```
and address given comments and patterns.
Most of the changes boiled down to just using fold expressions rather than initializer_list.
While doing this I also discovered that Clang by default restricts the depth of fold expressions to 256 elements. I specifically hit this with `TestDialect` in `addOperations`. I opted to not replace it with fold expressions because of that but instead adding a comment documenting the issue.
If any other functions may be called with more than 256 elements in the future we might have to revert other parts as well.
I don't think this is a common occurence besides the `TestDialect` however. If need be, this could potentially be fixed via `mlir-tblgen` in the future.
Differential Revision: https://reviews.llvm.org/D131323
This has previously been done for `mlir-opt` and `mlir-reduce` and roughly the same approach has been done here.
The use case for having a separate library is that it is easier for downstream to make custom TableGen backends/executable that work on top of the utilities that are defined in `mlir/TableGen`.
The customization point here is the same one as for any upstream TableGen backends: One can add a new generator by simply creating a global instance of `mlir::GenRegistration`.
Differential Revision: https://reviews.llvm.org/D131112
Based on `spv.ISubBorrow` from D127909.
Also resolved some clang-tidy warnings.
Reviewed By: antiagainst, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D131281
Jeff Niu