Fix an off-by-one error in extended umul extension for WebGPU.
Revert to the long multiplication algorithm originally added to wide
integer emulation, which was deleted in D139776. It is much easier
to see why it is correct.
Add runtime tests based on the mlir-vulkan-runner. These run both with
and without umul extension.
Issue: https://github.com/llvm/llvm-project/issues/59563
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D141085
This revision extends the LLVMImportDialectInterface to make the import
of LLVM IR instruction-level metadata extensible. It extends the
signature of the existing dialect interface to provide a method to
import specific metadata kinds and attach them to the imported
operation. The conversion function can rely on the ModuleImport class
to perform support tasks.
The revision implements the second part of the
"extensible llvm ir import" rfc:
https://discourse.llvm.org/t/rfc-extensible-llvm-ir-import/67256/6
The interface method names changed a bit compared to the suggested
design. The hook to set the instruction level metadata is now called
setMetadataAttrs and takes the metadata kind as an additional parameter.
We do not hand in the original LLVM IR instruction since it is not used
at this point. Importing named module-level meta data can be added in a
later stage after gaining some experience with this extension mechanism.
Depends on D140374
Reviewed By: ftynse, Dinistro
Differential Revision: https://reviews.llvm.org/D140556
The revision introduces the LLVMImportDialectInterface to make the
import of LLVM IR intrinsics extensible. It uses a dialect interface
that enables external projects to provide their own conversion functions
for custom intrinsics. These conversion functions can rely on the
ModuleImport class to perform support tasks such as mapping LLVM
values to MLIR values or for converting types between the two worlds.
The implementation largely mirrors the export implementation. One major
difference is the dispatch to the appropriate dialect interface, since
LLVM IR intrinsics have no direct association to an MLIR dialect. The
dialect interfaces thus have to publish the supported intrinsics to
ensure incoming conversion calls are dispatched to the right dialect
interface.
The revision implements the extensible intrinsic import discussed as
part of the "extensible llvm ir import" rfc:
https://discourse.llvm.org/t/rfc-extensible-llvm-ir-import/67256/6
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D140374
Fix incorrect markdown generated by mlir-tblgen for an InterfaceMethod
that includes a body. Previously, this would cause the next method to
show up on the same line and produce incorrect markdown. Newlines would
only be added if the method did _not_ provide a body. E.g., previously
this was generating markdown like:
some function comment#### `next method`
This change makes this generate as:
some function comment
#### `next method`
Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D140590
For cases where we can automatically construct the Attribute allow for more
user-friendly input. This is consistent with C++ builder generation as well
choice of which single builder to generate here (most
specialized/user-friendly).
Registration of attribute builders from more pythonic input is all Python side.
The downside is that
* extra checking to see if user provided a custom builder in op builders,
* the ODS attribute name is load bearing
upside is that
* easily change these/register dialect specific ones in downstream projects,
* adding support/changing to different convenience builders are all along with
the rest of the convenience functions in Python (and no additional changes
to tablegen file or recompilation needed);
Allow for both building with Attributes as well as raw inputs. This change
should therefore be backwards compatible as well as allow for avoiding
recreating Attribute where already available.
Differential Revision: https://reviews.llvm.org/D139568
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
The call sites block std::optional migration.
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This is part of an effort to migrate from llvm::Optional to
std::optional. This patch changes the way mlir-tblgen generates .inc
files, and modifies tests and documentation appropriately. It is a "no
compromises" patch, and doesn't leave the user with an unpleasant mix of
llvm::Optional and std::optional.
A non-trivial change has been made to ControlFlowInterfaces to split one
constructor into two, relating to a build failure on Windows.
See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D138934
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
The assert message was previously ignored. The lowered IR now calls `puts` it in case of a failed assertion.
Differential Revision: https://reviews.llvm.org/D138647
On macOS, hardcoding the path of bash leads to a failure in executing
update_core_linalg_named_ops.sh, due to an old version of bash being
present in that location.
Signed-off-by: Ramkumar Ramachandra <r@artagnon.com>
Differential Revision: https://reviews.llvm.org/D139942
Instead of exiting in the middle of the import handle errors more
gracefully by printing an error message and returning failure. The
revision handles and tests the import of unsupported instructions,
values, constants, and intrinsics.
Depends on D139404
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D139405
The remove*Attr methods were not being generated with the correct
camelcase method.
Depends on D139470
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D139471
The doc generator currently has the use of `!` as prefix hardcoded, despite being incorrect for Attributes. These start with `#`.
This patch fixes that little issue by using `#` for AttrDefs and `!` for TypeDefs in the `Syntax` field of the generated Markdown file.
Differential Revision: https://reviews.llvm.org/D139524
This covers `SDot`, `SUDot`, and `UDot`. The `*AccSat` version will be
added in a follow-up revision.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139242
It introduces a pattern that swaps `linalg.generic + tensor.pack` to
`tensor.pack + linalg.generic`. It requires all the iteration types
being parallel; the indexing map of output operand is identiy. They can
all be relaxed in the future.
The user can decide whether the propagation should be applied or not by
passing a control function.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D138882
Currently, assemblyFormat `custom<A>($a) custom<B>($b)` has different spacing
if used for Ops vs Attrs/Types. Ops insert a space if needed before the custom directive,
while attributes and types do not.
This leads to the following two patterns in attributes / types:
```
# 1. Whitespace literal
let assemblyFormat = "... ` ` custom<A>($a)"
# 2. Custom printer code includes spacing
void printB(...) {
printer << ' ' << b;
}
```
Moving this spacing into the generated code allows for some cleanup in mlir and
improves the consistency of custom directives.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D138235
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
TensorCopyInsertion should not have been exposed as a pass. This was a flaw in the original design. It is a preparation step for bufferization and certain transforms (that would otherwise be legal) are illegal between TensorCopyInsertion and actual rewrite to MemRef ops. Therefore, even if broken down as two separate steps internally, they should be exposed as a single pass.
This change affects the sparse compiler, which uses `TensorCopyInsertionPass`. A new `SparsificationAndBufferizationPass` is added to replace all passes in the sparse tensor pipeline from `TensorCopyInsertionPass` until the actual bufferization (rewrite to memref/non-tensor). It is generally unsafe to run arbitrary passes in-between, in particular passes that hoist tensor ops out of loops or change SSA use-def chains along tensor ops.
Differential Revision: https://reviews.llvm.org/D138915
Currently, the import of LLVMIR fails if the program contains debug
intrinsics. The revision adds support to import debug intrinsics that
have no debug expression attached and drops all debug intrinsics with a
non-empty debug expression. It also moves the existing debug intrinsics
into the "intr" namespace by deriving from LLVM_IntrOp.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D138405
This allows writing simple e2e tests where we can check for the proper materialization
of specific LLVM IR (e.g. `llvm.intr.fmuladd`).
Differential Revision: https://reviews.llvm.org/D138776
Instead of importing constant expressions recursively, the revision
walks all dependencies of an LLVM constant iteratively. The actual
conversion then iterates over a list of constants and all intermediate
constant values are added to the value mapping. As a result, an LLVM IR
constant maps to exactly one MLIR operation per function. The revision
adapts the existing tests since the constant ordering changed for
aggregate types. Additionally, it adds extra tests that mix aggregate
constants and constant expressions.
Depends on D137416
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D137559
This allows the MLIR transformer to see the command line options and
make desicions based on them. No change upstream, but my use-case is to
look at the entry point name and type to make sure I can use them.
Differential Revision: https://reviews.llvm.org/D137861
The self type is handled separately from normal parameters, and
the use of the params directive currently breaks attributes that
want to use it (e.g. in a struct directive).
Differential Revision: https://reviews.llvm.org/D137732
[RFC: EnumAttr for iterator types in Linalg](https://discourse.llvm.org/t/rfc-enumattr-for-iterator-types-in-linalg/64535)
This affect touches and probably breaks most of the code that creates `linalg.generic`. A fix would be to replace calls to `getParallelIteratorTypeName/getReductionIteratorTypeName` with `mlir::utils::IteratorType::parallel/reduction` and types from `StringRef` to `mlir::utils::IteratorType`.
Due to limitations of tablegen, shared C++ definition of IteratorType enum lives in StructuredOpsUtils.td, but each dialect should have it's own EnumAttr wrapper. To avoid conflict, all enums in a dialect are put into a separate file with a separate tablegen rule.
Test dialect td files are refactored a bit.
Printed format of `linalg.generic` temporarily remains unchanged to avoid breaking code and tests in the same change.
Differential Revision: https://reviews.llvm.org/D137658
Up until now PDL(L) has not supported dialect conversion because we had no
way of remapping values or integrating with type conversions. This commit
rectifies that by adding a new "pattern configuration" concept to PDL. This
essentially allows for attaching external configurations to patterns, which
can hook into pattern events (for now just the scope of a rewrite, but we
could also pass configs to native rewrites as well). This allows for injecting
the type converter into the conversion pattern rewriter.
Differential Revision: https://reviews.llvm.org/D133142
The KeyTy of attribute/type storage classes provide enough information for
automatically implementing the necessary sub element interface methods. This
removes the need for derived classes to do it themselves, which is both much
nicer and easier to handle certain invariants (e.g. null handling). In cases where
explicitly handling for parameter types is necessary, they can provide an implementation
of `AttrTypeSubElementHandler` to opt-in to support.
This tickles a few things alias wise, which annoyingly messes with tests that hard
code specific affine map numbers.
Differential Revision: https://reviews.llvm.org/D137374
