As of several months ago, both ArithToLLVM and ArithToSPIRV have
native support for integer min and max operations. Since these are all
the targets available in MLIR core, the need to "expand" arith.minui,
arith.minsi, arith,maxsi, and arith.manxui to more primitive
operations is to longer present.
Therefore, the expanding of integer min and max operations in Arith,
while correct, is likely to lead to performance loss by way of
misoptimization further down the line, and is no longer needed for
anyone's correctness.
This change may break downstream tests, but will not affect the
semantics of MLIR programs.
arith.minf and arith.maxf have a lot of underlying complexity due to
the many different possible NaN and signed zero semantics available on
various platforms, and so removing their expansion is left to a future
commit.
Reviewed By: ThomasRaoux, Mogball
Differential Revision: https://reviews.llvm.org/D140856
This revision folds arith.shrui, arith.shrsi and arith.shli with zero
rhs to lhs.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D140749
We shouldn't be checking things that are guaranteed by the op's verifier.
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D140610
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
- Add a fold for `mulsi_extended(x, 1)`
- Add folds to demote wide integer multiplication to `mul*i_extended` when the result is shifted
and truncated: `trunci(shrui(mul(*ext(x), *ext(y)), c)) -> mul*i_extended(x, y)`
Reviewed By: Mogball, jpienaar
Differential Revision: https://reviews.llvm.org/D139778
- Use `ConstantLikeMatcher` instead of matching `Arith_ConstantOp`
- Reflow some defs to fit the line limit
Suggested by @jpienaar and @Mogball in https://reviews.llvm.org/D139778.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D139941
This reverts commit 834c17f618ce87b14446e42250d924b8d5f01abe.
Revert to properly address post-commit comments by @jpienaar
under https://reviews.llvm.org/D139778.
- Add a fold for `mulsi_extended(x, 1)`
- Add folds to demote wide integer multiplication to `mul*i_extended` when the result is shifted
and truncated: `trunci(shrui(mul(*ext(x), *ext(y)), c)) -> mul*i_extended(x, y)`
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D139778
Using `arith.mului_extended` makes it much simpler to emulate wide
integer multiplication.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139776
Demote `arith.addui_extended` to `arith.addi` when the 'overflow'
result has no uses.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139722
The goal is to make the naming of the future `_extended` ops more
consistent. With unsigned addition, the carry value/flag and overflow
bit are the same, but this is not true when it comes to signed addition.
Also rename the second result from `carry` to `overflow`.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D139569
The pass was not checking for uninitialized states due to dead code.
This patch also makes LLVMFuncOp correctly return a null body when it is
external.
Fixes#58807
Depends on D139388
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D139389
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
MemRef has been accepting a general Attribute as memory space for
a long time. This commits updates bufferization side to catch up,
which allows downstream users to plugin customized symbolic memory
space. This also eliminates quite a few `getMemorySpaceAsInt`
calls, which is deprecated.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D138330
During elementwise fusion the fillOp's value was directly
referred without casting which can create mismatching dtypes.
Reviewed By: mravishankar, ThomasRaoux
Differential Revision: https://reviews.llvm.org/D137447
The folder used `cast<IntegerType>` which would segfault if the type were
a vector type. Handle this case appropriately and avoid failure.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D137345
Switch to using an optional group in the assembly format instead of a
custom directive. There's no change to the actual printed format.
Reviewed By: vzakhari
Differential Revision: https://reviews.llvm.org/D137087
This diff adds initial (partial) support for "fastmath" attributes for floating
point operations in the arithmetic dialect. The "fastmath" attributes are
implemented using a default-valued bit enum. The defined flags currently mirror
the fastmath flags in the LLVM dialect (and in LLVM itself). Extending the
set of flags (if necessary) is left as a future task.
In this diff:
- Definition of FastMathAttr as a custom attribute in the Arithmetic dialect
that inherits from the EnumAttr class.
- Definition of ArithFastMathInterface, which is an interface that is
implemented by operations that have an arith::fastmath attribute.
- Declaration of a default-valued fastmath attribute for unary and (some) binary
floating point operations in the Arithmetic dialect.
- Conversion code to lower arithmetic fastmath flags to LLVM fastmath flags
NOT in this diff (but planned or currently in progress):
- Documentation of flag meanings
- Addition of FastMathAttr attributes to other dialects that might lower to the
Arithmetic dialect (e.g. Math and Complex)
- Folding/rewrite implementations that are enabled by fastmath flags
- Specification of fastmath values from Python bindings (pending other in-
progress diffs)
Reviewed By: mehdi_amini, vzakhari
Differential Revision: https://reviews.llvm.org/D126305
This allows for setting an attribute using the underlying C++ type,
which is generally much nicer to interact with than the attribute type.
Differential Revision: https://reviews.llvm.org/D135838
Add a new pass and conversions to emulate wide integer operations over memrefs.
The emulation is implemented on top of the existing pass to emulate wide integer arith ops.
Improve naming in the arith pass to avoid potential name clashes.
Reviewed By: antiagainst
Differential Revision: https://reviews.llvm.org/D135722
Print unsupported types on match failures.
Suggested by @Mogball and @jpienaar in D135204.
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D135673
This allows more precise control over which patterns to pick to
expand arithmetic ops. Previously ceil/floor division epxansion
is only available together with various min/max op expansion.
Reviewed By: ThomasRaoux
Differential Revision: https://reviews.llvm.org/D135479
This is required to be able to cast integer type to a potential larger index using zero-extend cast.
There is a larger change under discussion to move index ops in a separate dialect: https://discourse.llvm.org/t/rfc-index-dialect/65540/
Based on timing of this work this patch can be included as part of this effort but as a short term solution we may want to add this op to arithmetic dialect for now in order to fill the gap.
Reviewed By: Mogball, stellaraccident
Differential Revision: https://reviews.llvm.org/D135089
