Use `mlir_target_link_libraries()` to link dependencies of libraries
that are not included in libMLIR, to ensure that they link to the dylib
when they are used in Flang. Otherwise, they implicitly pull in all
their static dependencies, effectively causing Flang binaries to
simultaneously link to the dylib and to static libraries, which is never
a good idea.
I have only covered the libraries that are used by Flang. If you wish, I
can extend this approach to all non-libMLIR libraries in MLIR, making
MLIR itself also link to the dylib consistently.
In order to meaningfully generate getters and setters from IRDL, it
makes sense to embed the names of operands, results, etc. in the IR
definition. This PR introduces this feature. Names are constrained
similarly to TableGen names.
This commit adds new wrappers around the MLIR Vulkan runtime which
implement the mgpu* APIs (as generated by GPUToLLVMConversionPass), adds
an optional LLVM lowering to the Vulkan runner mlir-opt pipeline based
on GPUToLLVMConversionPass, and migrates several of the
mlir-vulkan-runner tests to use mlir-cpu-runner instead, together with
the new pipeline and wrappers.
This is a further incremental step towards eliminating
mlir-vulkan-runner and its associated pipeline, passes and wrappers
(#73457). This commit does not migrate all of the tests to the new
system, because changes to the mgpuLaunchKernel ABI will be necessary to
support the tests that use multi-dimensional memref arguments.
This fixes a conflict between the version of LLVM linked against by the
runner and the unrelated version of LLVM that may be dynamically loaded
by a graphics driver. (Relevant to #73457: fixes loading certain Vulkan
drivers.)
Recommit of f879da799b4e112d79243dde6d299259d8359eeb, which had been
reverted by d8d30a96031bfdad3e2c424e14a4247c14980cb5 due to it causing
UBSan/ASan/HWASan/MSan build failures.
This reverts commit f879da799b4e112d79243dde6d299259d8359eeb. The change
to not export certain symbols apparently broke the UBsan/Asan buildbot,
because the DSO for the sanitizer wants to link to them.
This fixes a conflict between the version of LLVM linked against by the
runner and the unrelated version of LLVM that may be dynamically loaded
by a graphics driver. (Relevant to #73457: fixes loading certain Vulkan
drivers.)
Since the property system isn't currently in heavy use, it's probably
the right time to fix a choice I made when expanding ODS property
support.
Specifically, most of the property subclasses, like OptionalProperty or
IntProperty, wrote out the word "Property" in full. The corresponding
classes in the Attribute hierarchy uses the short-form "Attr" in those
cases, as in OptionalAttr or DefaultValuedAttr.
This commit changes all those uses of "Property" to "Prop" in order to
prevent excessively verbose tablegen files that needlessly repeat the
full name of a core concept that can be abbreviated.
So, this commit renames all the FooProperty classes to FooProp, and
keeps the existing names as alias with a Deprecated<> on them to warn
people.
In addition, this commit updates the documentation around properties to
mention the constraint support.
Do not run `cf-to-llvm` as part of `func-to-llvm`. This commit fixes
https://github.com/llvm/llvm-project/issues/70982.
This commit changes the way how `func.func` ops are lowered to LLVM.
Previously, the signature of the entire region (i.e., entry block and
all other blocks in the `func.func` op) was converted as part of the
`func.func` lowering pattern.
Now, only the entry block is converted. The remaining block signatures
are converted together with `cf.br` and `cf.cond_br` as part of
`cf-to-llvm`. All unstructured control flow is not converted as part of
a single pass (`cf-to-llvm`). `func-to-llvm` no longer deals with
unstructured control flow.
Also add more test cases for control flow dialect ops.
Note: This PR is in preparation of #120431, which adds an additional
GPU-specific lowering for `cf.assert`. This was a problem because
`cf.assert` used to be converted as part of `func-to-llvm`.
Note for LLVM integration: If you see failures, add
`-convert-cf-to-llvm` to your pass pipeline.
Do not run `arith-to-llvm` as part of `func-to-llvm`. This commit partly
fixes#70982.
Also simplify the pass pipeline for two math dialect integration tests.
Note for LLVM integration: If you see failures, add `arith-to-llvm` to your pass pipeline.
Give the properties from tablegen a `predicate` field that holds the
predicate that the property needs to satisfy, if one exists, and hook
that field up to verifier generation.
Fixes a crash (assertion failure) in `mlir-tblgen -emit-enum-doc` caused
by calling `EnumAttr()` for the wrong type of `Record *`: `EnumAttr`
rather than `EnumAttrInfo` as asserted.
Compare the corresponding line in `emitDialectDoc()`:
0ad6be1927/mlir/tools/mlir-tblgen/OpDocGen.cpp (L532)
Co-authored-by: Malte Dehling <m.dehling@samsung.com>
The printer for prop-dict would elide properties that had their default
value, such as optional properties that were not present. The parser
would similarly not raise an error if such a key was missing. However,
after not raising an error, the parser would attempt to convert the null
attribute to a property anyway, causing failures.
This commit fixes the issue and adds tests.
Note that PointerUnion::{is,get} have been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
I'm not touching PointerUnion::dyn_cast for now because it's a bit
complicated; we could blindly migrate it to dyn_cast_if_present, but
we should probably use dyn_cast when the operand is known to be
non-null.
In 10ef20f6a629797d81252de143117e2a0bc6556d I dropped $test_libs
from $LIBS to handle them separately for the mlir-opt tool.
However, they should still include them in LINK_LIBS for the
MLIRMlirOptMain library.
While MLIR currently supports building a libMLIR.so, it does not support
actually linking against it for its own tools. When building with LTO,
this means we have to relink the world for every tool, and the resulting
binaries are large.
This adds basic support for MLIR_LINK_MLIR_DYLIB, modelled after how
CLANG_LINK_CLANG_DYLIB is implemented: Libraries that are part of
libMLIR.so should be added via mlir_target_link_libraries instead of
target_link_libraries. This will replace them with libMLIR.so if
MLIR_LINK_MLIR_DYLIB is enabled.
This adds basic support, I think there are two more things that can be
done here:
* C API unit tests should link against libMLIR-C.so. Currently these
still link statically.
* Linking the test libs (not part of libMLIR.so) still pulls in
dependencies statically that should come from libMLIR.so.
Adds a new mlir-opt test-only pass, -test-vulkan-runner-pipeline, which
runs a set of passes needed for mlir-vulkan-runner, and removes them
from the runner. The tests are changed to invoke mlir-opt with this flag
before invoking the runner. The passes moved are ones concerned with
lowering of the device code prior to serialization to SPIR-V. This is an
incremental step towards moving the entire pipeline to mlir-opt, to
align with other runners (see #73457).
The mlir-tblgen tool prevents the parameter of the build() constructor
for the first default-valued attribute of an operation from having a
default value to avoid ambiguity with the corresponding build()
constructor taking unwrapped value. However it does so even when earlier
wrapped unwrappable attribute would lift the ambiguity. This commit
relax the logic accordingly, which allows to remove a manual constructor
in Arith dialect.
The comment is misleading because attributes do not have
`elidePrintingDefaultValue` bit. It appears that
`elidePrintingDefaultValue` was never merged upstream (see:
https://reviews.llvm.org/D135398 ), but the comment was likely
introduced by mistake in a later revision
(https://reviews.llvm.org/D135993.).
This commit adds extra checks to the MemRef argument materializations in
the LLVM type converter. These materializations construct a
`MemRefType`/`UnrankedMemRefType` from the unpacked elements of a MemRef
descriptor or from a bare pointer.
The extra checks ensure that the inputs to the materialization function
are correct. It is possible that a user added extra type conversion
rules that convert MemRef types in a different way and the extra checks
ensure that we construct a MemRef descriptor only if the inputs are what
we expect.
This commit also drops a check around bare pointer materializations:
```
// This is a bare pointer. We allow bare pointers only for function entry
// blocks.
```
This check should not be part of the materialization function. Whether a
MemRef block argument is converted into a MemRef descriptor or a bare
pointer is decided in the lowering pattern. At the point of time when
materialization functions are executed, we already made that decision
and we should just materialize regardless of the input format.
This commit builds on and completes the work done in
9f6c632ecda08bfff76b798c46d5d7cfde57b5e9 to eliminate the need for a
separate mlir-spirv-cpu-runner binary. Since the MLIR processing is
already done outside this runner, the only real difference between it
and the mlir-cpu-runner is the final linking step between the nested
LLVM IR modules. By moving this step into mlir-cpu-runner behind a new
command-line flag (`--link-nested-modules`), this commit is able to
completely remove the runner component of the mlir-spirv-cpu-runner.
The runtime libraries and the tests are moved and renamed to fit into
the Execution Engine and Integration tests, following the model of the
similar migration done for the CUDA Runner in D97463.
The earlier PR(https://github.com/llvm/llvm-project/pull/104783) which
introduces
transpose and broadcast semantic to linalg.matmul was reverted due to
two failing
OpDSL test for linalg.matmul.
Since linalg.matmul is now defined using TableGen ODS instead of
Python-based OpDSL,
these test started failing and needs to be removed/updated.
This commit removes/updates the failing obsolete tests from below files.
All other files
were part of earlier PR and just cherry picked.
"mlir/test/python/integration/dialects/linalg/opsrun.py"
"mlir/test/python/integration/dialects/transform.py"
---------
Co-authored-by: Renato Golin <rengolin@systemcall.eu>
If we know the output arity at tablegen time, we can often just call
.result or .results directly.
This saves almost 1s in a JAX-based LLM benchmark building a mixture of
upstream dialects and StableHLO.
Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(with cPTR and cN being the capability equivalents of iPTR and iN).
Moreover, iPTRAny is already not itself regarded as an integer (calling
isInteger() will give false), so the "i" prefix is misleading, and it
stands out as different from all the other xAny that have a single
letter prefix denoting their type.
Thus, rename it to pAny, reflecting that it is an overloaded pointer
type, which could end up being specialised to an integer type, but does
not have to be.
This has been verified to have no effect on the generated files for LLVM
itself or any in-tree target beyond the replacement of the identifier
iPTRAny with pAny in GenVT.inc.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113733
Adds a new mlir-opt test-only pass, -test-spirv-cpu-runner-pipeline,
which runs the set of MLIR passes needed for the mlir-spirv-cpu-runner,
and removes them from the runner. The tests are changed to invoke
mlir-opt with this flag before running the runner. The eventual goal is
to move all host/device code generation steps out of the runner, like
with some of the other runners.
Recommit of 17e9752267ed9c81c8da87f3a6d0e01f130b0d04. It was reverted
due to a build failure, but the build failure had in fact already been
fixed in e7302319b52e3d231216d54d10622b0698928a96.
When an operation has no properties, no property struct is emitted. To avoid a compilation error, we should also skip emitting `setPropertiesFromParsedAttr`, `parseProperties` and `printProperties` in such cases.
Compilation error:
```
error: ‘Properties’ has not been declared
static ::llvm::LogicalResult setPropertiesFromParsedAttr(Properties &prop, ::mlir::Attribute attr, ::llvm::function_ref<::mlir::InFlightDiagnostic()> emitError);
```
Adds a new mlir-opt test-only pass, -test-spirv-cpu-runner-pipeline,
which runs the set of MLIR passes needed for the mlir-spirv-cpu-runner,
and removes them from the runner. The tests are changed to invoke
mlir-opt with this flag before running the runner. The eventual goal is
to move all host/device code generation steps out of the runner, like
with some of the other runners.
This issue is from https://github.com/llvm/llvm-project/pull/77668. I
encountered a build issue because it used Unicode. When I built MLIR on
Windows with Visual Studio 2022, I faced a build failure.
---------
Co-authored-by: Harrison Hao <harrison.hao@amd.com>
Print an error such as the following one before terminating program
execution.
```
mlir/test/Dialect/SparseTensor/convert_dense2sparse.mlir:26:8: remark: location of op
%0 = sparse_tensor.convert %arg0 : tensor<?xi32> to tensor<?xi32, #SparseVector>
^
LLVM ERROR: Failed to infer result type(s):
"sparse_tensor.positions"(...) {} : (index) -> ( ??? )
(stack trace follows)
```
Add an additional adaptor constructor that copies everything except for
the values. The values are provided with by a second parameter.
This commit is in preparation of merging the 1:1 and 1:N dialect
conversions. As part of that, a new `matchAndRewrite` function is added.
For details, see this RFC:
https://discourse.llvm.org/t/rfc-merging-1-1-and-1-n-dialect-conversions/82513
```c++
template <typename SourceOp>
class OpConversionPattern : public ConversionPattern {
public:
using OneToNOpAdaptor =
typename SourceOp::template GenericAdaptor<ArrayRef<ArrayRef<Value>>>;
virtual LogicalResult
matchAndRewrite(SourceOp op, OneToNOpAdaptor adaptor,
ConversionPatternRewriter &rewriter) const {
SmallVector<Value> oneToOneOperands =
getOneToOneAdaptorOperands(adaptor.getOperands());
// This OpAdaptor constructor is added by this commit.
return matchAndRewrite(op, OpAdaptor(oneToOneOperands, adaptor), rewriter);
}
};
```
Initial commit of a tool to help in textual rewrites of .mlir files.
This tool builds of of AsmParserState and is rather simple. Took some
inspiration from when I used clang's AST rewrites where I'd often treat
it as a "localizing" regex applicator in fallback cases, and started
with that as functionality. There though, one does have access to the
lower level info than here, but still a step up over sed over entire
file.
This aims to be helpful (e.g., rewrite syntax including best effort
inside comments) rather than bulletproof tool. It may even be better
suited under utils than tools. And most of the rewrites would be rather
short lived and might never make it upstream (while the helpers of those
rewrites may for future rewrites).
The layering at the moment is not ideal as it is reusing the
RewriteBuffer class from clang's rewrite engine. So only optionally
enabling where clang is also enable. There doesn't seem to be anything
clang specific there (the dep does pull in more dependencies than ideal,
but leaving both refactorings).
Additionally started it as a single file to prototype more easily,
planning to refactor later to include and libs for out of file usage.
This reverts commit 03483737a7a2d72a257a5ab6ff01748ad9cf0f75 and
99c8557, which is a fix-up on top of the former.
I'm reverting because this commit broke two tests:
mlir/test/python/integration/dialects/linalg/opsrun.py
mlir/test/python/integration/dialects/transform.py
See https://lab.llvm.org/buildbot/#/builders/138/builds/4872
I'm not familiar with the tests, so I'm leaving it to the original author
to either remove or adapt the broken tests, as discussed here:
https://github.com/llvm/llvm-project/pull/104783#issuecomment-2406390905
The main goal of this patch is to extend the semantic of 'linalg.matmul'
named op to include per operand transpose semantic while also laying out
a way to move ops definition from OpDSL to tablegen. Hence, it is
implemented in tablegen. Transpose semantic is as follows.
By default 'linalg.matmul' behavior will remain as is. Transpose
semantics can be appiled on per input operand by specifying the optional
permutation attributes (namely 'permutationA' for 1st input and
'permutationB' for 2nd input) for each operand explicitly as needed. By
default, no transpose is mandated for any of the input operand.
Example:
```
%val = linalg.matmul ins(%arg0, %arg1 : memref<5x3xf32>,
memref<5x7xf32>)
outs(%arg2: memref<3x7xf32>)
permutationA = [1, 0]
permutationB = [0, 1]
```
