Commit Graph

147 Commits

Author SHA1 Message Date
Prashant Kumar
5b702be1e8 [mlir][math] Convert math.fpowi to math.powf in case of non constant (#87472)
Convert math.fpowi to math.powf by converting dtype of power operand to
floating point.
2024-04-03 22:19:26 +05:30
Prashant Kumar
10a57f3aff [mlir][math] Expand powfI operation for constant power operand. (#87081)
-- Convert `math.fpowi` to a series of `arith.mulf` operations.
-- If the power is negative, we divide the result by 1.
2024-04-01 13:18:27 +05:30
Justin Fargnoli
35d55f2894 [NFC][mlir] Reorder declarePromisedInterface() operands (#86628)
Reorder the template operands of `declarePromisedInterface()` to match
`declarePromisedInterfaces()`.
2024-03-27 10:30:17 -07:00
srcarroll
d39ac3a8e0 [mlir][math] Reland 58ef9bec07 (#85436)
The previous implementation decomposes tanh(x) into
`(exp(2x) - 1)/(exp(2x)+1), x < 0`
`(1 - exp(-2x))/(1 + exp(-2x)), x >= 0`
This is fine as it avoids overflow with the exponential, but the whole
decomposition is computed for both cases unconditionally, then the
result is chosen based off the sign of the input. This results in doing
two expensive exp computations.

The proposed change avoids doing the whole computation twice by
exploiting the reflection symmetry `tanh(-x) = -tanh(x)`. We can
"normalize" the input to be positive by setting `y = sign(x) * x`, where
the sign of `x` is computed as `sign(x) = (float)(x > 0) * (-2) + 1`.
Then compute `z = tanh(y) `with the decomposition above for `x >=0` and
"denormalize" the result `z * sign(x)` to retain the sign. The reason it
is done this way is that it is very amenable to vectorization.

This method trades the duplicate decomposition computations (which takes
5 instructions including an extra expensive exp and div) for 4 cheap
instructions to compute the signs value

`arith.cmpf `(which is a pre-existing instruction in the previous impl)
`arith.sitofp`
`arith.mulf`
`arith.addf`
and 1 more instruction to get the right sign in the result
5. `arith.mulf`. 
Moreover, numerically, this implementation will yield the exact same
results as the previous implementation.

As part of the relanding, a casting issue from the original commit has
been fixed, i.e. casting bool to float with `uitofp`. Additionally a
correctness test with `mlir-cpu-runner` has been added.
2024-03-17 11:23:30 -05:00
Benjamin Maxwell
e74bcecd36 [mlir][math] Propagate scalability in polynomial approximation (#84949)
This simply updates the rewrites to propagate the scalable flags (which
as they do not alter the vector shape, is pretty simple).

The added tests are simply scalable versions of the existing vector
tests.
2024-03-15 20:08:52 +00:00
srcarroll
f75d164eea Revert "[mlir][math] Implement alternative decomposition for tanh (#8… (#85429)
…5025)"

This reverts commit 58ef9bec07.

There is a bool to float casting issue that needs to be sorted out to
make sure this is target independent
2024-03-15 14:39:57 -05:00
srcarroll
58ef9bec07 [mlir][math] Implement alternative decomposition for tanh (#85025)
The previous implementation decomposes `tanh(x)` into
`(exp(2x) - 1)/(exp(2x)+1), x < 0`
`(1 - exp(-2x))/(1 + exp(-2x)), x >= 0`
This is fine as it avoids overflow with the exponential, but the whole
decomposition is computed for both cases unconditionally, then the
result is chosen based off the sign of the input. This results in doing
two expensive `exp` computations.

The proposed change avoids doing the whole computation twice by
exploiting the reflection symmetry `tanh(-x) = -tanh(x)`. We can
"normalize" the input to be positive by setting `y = sign(x) * x`, where
the sign of `x` is computed as `sign(x) = (float)(x > 0) * (-2) + 1`.
Then compute `z = tanh(y)` with the decomposition above for `x >=0` and
"denormalize" the result `z * sign(x)` to retain the sign. The reason it
is done this way is that it is very amenable to vectorization.

This method trades the duplicate decomposition computations (which takes
5 instructions including an extra expensive `exp` and `div`) for 4 cheap
instructions to compute the signs value
1. `arith.cmpf` (which is a pre-existing instruction in the previous
impl)
2. `arith.sitofp`
3. `arith.mulf`
4. `arith.addf`

and 1 more instruction to get the right sign in the result
5. `arith.mulf`. Moreover, numerically, this implementation will yield
the exact same results as the previous implementation.
2024-03-14 19:18:56 -05:00
Johannes Reifferscheid
bcf9826a53 [MLIR] Expose approximation patterns for tanh/erf. (#82750)
These patterns can already be used via
populateMathPolynomialApproximationPatterns, but that includes a number
of other patterns that may not be needed.

There are already similar functions for expansion.

For now only adding tanh and erf since I have a concrete use case for
these two.
2024-02-23 13:15:08 +01:00
Ivan Butygin
35ef3994bf [mlir][vector] ND vectors linearization pass (#81159)
Common backends (LLVM, SPIR-V) only supports 1D vectors, LLVM conversion
handles ND vectors (N >= 2) as `array<array<... vector>>` and SPIR-V
conversion doesn't handle them at all at the moment. Sometimes it's
preferable to treat multidim vectors as linearized 1D. Add pass to do
this. Only constants and simple elementwise ops are supported for now.

@krzysz00 I've extracted yours result type conversion code from
LegalizeToF32 and moved it to common place.

Also, add ConversionPattern class operating on traits.
2024-02-13 15:30:58 +03:00
Mehdi Amini
d4933b3241 Apply clang-tidy fixes for readability-identifier-naming in PolynomialApproximation.cpp (NFC) 2024-01-22 17:34:56 -08:00
Krzysztof Drewniak
05e85e4fc5 [mlir][Math] Add pass to legalize math functions to f32-or-higher (#78361)
Since most of the operations in the `math` dialect don't have
low-precision implementations, add the -math-legalize-to-f32 pass that
goes through and brackets low-precision math funcitons (like `math.sin
%0 : f16`) with `arith.extf` and `arith.truncf`. This preserves the
original semantics of the math operation but allows lowering to proceed.

Versions of this lowering are already implicitly present in some passes,
like ConvertGPUToROCDL. However, because those are implicit rewrites,
they hide the floating-point extension and truncation, preventing anyone
from writing passes that operate on those implitic extf/truncf pairs.

Exposing this legalization explicitly is needed to allow lowening 8-bit
floats on AMD GPUs, as the implementation of extf and truncf on that
platform requires the complex logic found in ArithToAMDGPU, which runs
before the GPU to ROCDL lowering.
2024-01-18 09:37:43 -06:00
Vivek Khandelwal
b8dca4fa72 [mlir][math] Add math.acosh|asin|asinh|atanh op (#77463)
Signed-Off By: Vivek Khandelwal <vivekkhandelwal1424@gmail.com>
2024-01-10 13:39:32 +01:00
Justin Fargnoli
b43c50490c [mlir] Declare promised interfaces for the ConvertToLLVM extension (#76341)
This PR adds promised interface declarations for
`ConvertToLLVMPatternInterface` in all the dialects that support the
`ConvertToLLVM` dialect extension.

Promised interfaces allow a dialect to declare that it will have an
implementation of a particular interface, crashing the program if one
isn't provided when the interface is used.
2024-01-08 20:19:18 -08:00
Rob Suderman
aa165edca8 [mlir][math] Added math.sinh with expansions to math.exp (#75517)
Includes end-to-end tests for the cpu running, folders using `libm` and
lowerings to the corresponding `libm` operations.
2023-12-15 11:35:40 -08:00
Sungsoon Cho
762964e97f Add cosh op to the math dialect. (#75153) 2023-12-13 12:25:37 +01:00
Frederik Harwath
f7250179e2 Implement acos operator in MLIR Math Dialect (#74584)
Required for torch-mlir.
Cf. llvm/torch-mlir#2604 "Implement torch.aten.acos".
2023-12-08 09:08:43 -08:00
Ivan Butygin
5dce74817b [mlir][ub] Add poison support to CommonFolders.h
Return poison from foldBinary/unary if argument(s) is poison. Add ub dialect as dependency to affected dialects (arith, math, spirv, shape).
Add poison materialization to dialects. Add tests for some ops from each dialect.
Not all affected ops are covered as it will involve a huge copypaste.

Differential Revision: https://reviews.llvm.org/D159013
2023-09-07 12:30:29 +02:00
Balaji V. Iyer
f66e4bd67a [mlir][math] Modify math.powf to handle negative bases.
Powf expansion currently returns NaN when the base is negative.
This is because taking natural log of a negative number gives
NaN. This patch will square the base and half the exponent, thereby
getting around the negative base problem.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D158797
2023-08-25 15:35:05 -07:00
Alexander Shaposhnikov
fe355a44e7 [MLIR][Math] Add support for f64 in the expansion of math.roundeven
Add support for f64 in the expansion of math.roundeven.
Associated GitHub issue: https://github.com/openxla/iree/issues/13522
This is based on the offline discussion and essentially recommits
https://reviews.llvm.org/D158234.

Test plan: ninja check-mlir check-all
2023-08-24 21:41:26 +00:00
Alexander Shaposhnikov
d22883e384 Revert "[MLIR][Math] Add support for f16 in the expansion of math.roundeven"
This reverts commit 40bf36319e.
The build bot ppc64le-mlir-rhel-test got broken by these changes,
see https://lab.llvm.org/buildbot#builders/88/builds/61048 .
2023-08-18 18:20:52 +00:00
Alexander Shaposhnikov
40bf36319e [MLIR][Math] Add support for f16 in the expansion of math.roundeven
Add support for f16 in the expansion of math.roundeven.
Associated GitHub issue: https://github.com/openxla/iree/issues/13522
This version addresses the build issues on Windows reported on
https://reviews.llvm.org/D157204

Test plan: ninja check-mlir check-all

Differential revision: https://reviews.llvm.org/D158234
2023-08-18 17:48:34 +00:00
Alexander Shaposhnikov
f745c91f61 Revert "[MLIR][Math] Add support for f16 in the expansion of math.roundeven"
This reverts commit b96f6cf629
since it has broken some Windows build bots
(see https://reviews.llvm.org/D157204).
Will recommit a fixed version later.
2023-08-17 23:22:05 +00:00
Alexander Shaposhnikov
b96f6cf629 [MLIR][Math] Add support for f16 in the expansion of math.roundeven
Add support for f16 in the expansion of math.roundeven.
Associated GitHub issue: https://github.com/openxla/iree/issues/13522

Test plan: ninja check-mlir check-all

Differential revision: https://reviews.llvm.org/D157204
2023-08-17 18:40:26 +00:00
Jacques Pienaar
75bd41f61d [mlir][polyapprox] Use llvm::numbers for constants.
Fixes windows build.
2023-06-24 17:03:39 -07:00
Robert Suderman
0bedb667af [mlir][math] Improved math.atan approximation
Used the cephes numerical approximation for `math.atan`. This is a
significant accuracy improvement over the previous taylor series
approximation.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D153656
2023-06-23 17:25:34 -07:00
Robert Suderman
710dc7282a [mlir][math] Modified the 'math.exp' lowering for higher precision
The existing lowering has lower precision for certain use cases, e.g.
tanh. Improved version should demonstrate an overall higher level of precision.

Reviewed By: cota, jpienaar

Differential Revision: https://reviews.llvm.org/D153592
2023-06-23 12:25:18 -07:00
Ivan Butygin
ee8b8d6b58 [mlir][math] Uplift from arith to math.fma
Add pass to uplift from arith mulf + addf ops to math.fma if fastmath flags allow it.

Differential Revision: https://reviews.llvm.org/D152633
2023-06-18 17:11:21 +02:00
Tres Popp
5550c82189 [mlir] Move casting calls from methods to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in addition to defining methods with the same name.
This change begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.

Caveats include:
- This clang-tidy script probably has more problems.
- This only touches C++ code, so nothing that is being generated.

Context:
- https://mlir.llvm.org/deprecation/ at "Use the free function variants
  for dyn_cast/cast/isa/…"
- Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443

Implementation:
This first patch was created with the following steps. The intention is
to only do automated changes at first, so I waste less time if it's
reverted, and so the first mass change is more clear as an example to
other teams that will need to follow similar steps.

Steps are described per line, as comments are removed by git:
0. Retrieve the change from the following to build clang-tidy with an
   additional check:
   https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
1. Build clang-tidy
2. Run clang-tidy over your entire codebase while disabling all checks
   and enabling the one relevant one. Run on all header files also.
3. Delete .inc files that were also modified, so the next build rebuilds
   them to a pure state.
4. Some changes have been deleted for the following reasons:
   - Some files had a variable also named cast
   - Some files had not included a header file that defines the cast
     functions
   - Some files are definitions of the classes that have the casting
     methods, so the code still refers to the method instead of the
     function without adding a prefix or removing the method declaration
     at the same time.

```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
               -header-filter=mlir/ mlir/* -fix

rm -rf $BUILD_DIR/tools/mlir/**/*.inc

git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\
            mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\
            mlir/lib/**/IR/\
            mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\
            mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\
            mlir/test/lib/Dialect/Test/TestTypes.cpp\
            mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\
            mlir/test/lib/Dialect/Test/TestAttributes.cpp\
            mlir/unittests/TableGen/EnumsGenTest.cpp\
            mlir/test/python/lib/PythonTestCAPI.cpp\
            mlir/include/mlir/IR/
```

Differential Revision: https://reviews.llvm.org/D150123
2023-05-12 11:21:25 +02:00
Uday Bondhugula
20b12fa898 Fix MathTransforms library dependencies
The dependencies were set up improperly likely due to past code
locations. MathTransforms shouldn't depend on VectorUtils which add a
whole bunch of additional dependencies; it instead depends on the SCF
dialect.

Differential Revision: https://reviews.llvm.org/D149797
2023-05-04 05:41:48 +05:30
Ramiro Leal-Cavazos
44baa65589 Revert "Revert "Fix handling of special and large vals in expand pattern for round" and "Add pattern that expands math.roundeven into math.round + arith""
This reverts commit 87cef78fa1.

The issue in the original revert is that a lit test expecting a `-nan`
as an output was failing on M2. Since the IEEE 754-2008 standard does
not require the sign to be printed when displaying a `nan`, this
commit changes the `CHECK` for `-nan` to one that checks the result
value bitcasted to an `i32` to ensure that input is being left
unchanged. This check should now be independent of platform being used
to run test.

Reviewed By: jpienaar, mehdi_amini

Differential Revision: https://reviews.llvm.org/D148941
2023-04-22 07:15:40 -07:00
Mehdi Amini
87cef78fa1 Revert "Fix handling of special and large vals in expand pattern for round" and "Add pattern that expands math.roundeven into math.round + arith"
This reverts commit 8d2bae9abd and
commit ab2fc9521e.

Tests are broken on Mac M2
2023-04-21 00:16:32 -06:00
Rahul Kayaith
6089d612a5 [mlir] Prevent implicit downcasting to interfaces
Currently conversions to interfaces may happen implicitly (e.g.
`Attribute -> TypedAttr`), failing a runtime assert if the interface
isn't actually implemented. This change marks the `Interface(ValueT)`
constructor as explicit so that a cast is required.

Where it was straightforward to I adjusted code to not require casts,
otherwise I just made them explicit.

Depends on D148491, D148492

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D148493
2023-04-20 16:31:54 -04:00
Rahul Kayaith
00e3566d6c [mlir][arith] Add arith.constant materialization helper
This adds `arith::ConstantOp::materialize`, which builds a constant from
an attribute and type only if it would result in a valid op. This is
useful for dialect `materializeConstant` hooks, and allows for removing
the previous `Attribute, Type` builder which was only used during
materialization.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D148491
2023-04-20 16:31:52 -04:00
Ramiro Leal-Cavazos
8d2bae9abd Add pattern that expands math.roundeven into math.round + arith
This commit adds a pattern that expands `math.roundeven` into
`math.round` + some ops from `arith`. This is needed to be able to run
`math.roundeven` in a vectorized manner.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D148285
2023-04-20 12:48:12 -07:00
Ramiro Leal-Cavazos
ab2fc9521e Fix handling of special and large vals in expand pattern for round
The current expand pattern for `math.round` does not handle the
special values -0.0, +-inf, and +-nan correctly. It also does not
properly handle values with magnitude |x| >= 2^23. Lastly, the pattern
generates invalid IR when the input to `math.round` is a vector. This
patch fixes these issues.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D148398
2023-04-20 18:08:19 +00:00
Balaji V. Iyer
2d4e856709 [mlir][math] Expand math.powf to exp, log and multiply
Powf functions are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will decompose the
powf function into log of exponent multiplied by log of base and raise
it to the exp.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D148164
2023-04-14 14:04:19 +00:00
Balaji V. Iyer
be9115788c [mlir][math] Expand math.round to truncate, compare and increment.
Round functions are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will decompose the
roundf function by adding 0.5 to positive number to input
(subtracting for negative) following by a truncate.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D148026
2023-04-13 18:02:10 +00:00
Balaji V. Iyer
4da96515ea [mlir][math] Expand math.exp2 to use math.exp.
Exp2 functions are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will expand the exp2
function to use exp2 with the input multiplied by ln2 (natural log).

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D148064
2023-04-13 16:06:04 +00:00
Balaji V. Iyer
2217888d2c [mlir][math] Expand math.ceilf to truncate, compares and increments
Ceilf are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will break down
a ceilf function to truncate followed by an increment if the
truncated value is smaller than the input value.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D147974
2023-04-11 13:52:45 +00:00
Balaji V. Iyer
af9eb1e384 [mlir][math] Expand math.floorf to truncate, compares and increments
Floorf are pushed directly to libm. This is problematic for
situations where libm is not available. This patch will break down
a floorf function to truncate followed by an increment for negative
values, if necessary.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D147966
2023-04-10 21:04:27 +00:00
Balaji V. Iyer
a7c2102d98 [mlir][math]Expand Fused math.fmaf to a multiply-add
Fused multiply and add are being pushed directly to the libm. This is problematic
for situations where libm is not available. This patch will break down a fused multiply and
add into a multiply followed by an add.

Reviewed By: rsuderman

Differential Revision: https://reviews.llvm.org/D147811
2023-04-07 22:14:56 +00:00
Robert Suderman
711c58938f [mlir][math] Update math arith expansions for vectorization
The math arithmetic expansions do not support vectorized types.
Updated the lowerings so that they support vectorized types. This
includes a different implementation for `math.ctlz` to be a binary
search and not have variable termination time.

Reviewed By: jpienaar, NatashaKnk

Differential Revision: https://reviews.llvm.org/D147289
2023-04-06 18:42:01 +00:00
Robert Suderman
57e1943e8f [mlir] Add support for non-f32 polynomial approximation
Polynomial approximations assume F32 values. We can convert all non-f32
cases to operate on f32s with intermediate casts.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D146677
2023-03-27 21:57:57 +00:00
Nicolas Vasilache
203fad476b [mlir][DialectUtils] Cleanup IndexingUtils and provide more affine variants while reusing implementations
Differential Revision: https://reviews.llvm.org/D145784
2023-03-14 03:44:59 -07:00
Robert Suderman
6b53881048 [mlir][math] Add math.cbrt polynomial approximation
Cbrt can be approximated with some relatively simple polynomial
operators. This includes a lit test validating the implementation
and some run tests that validate numerical correct.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D145019
2023-03-06 13:29:49 -08:00
Robert Suderman
740e2e908c [mlir][math] Math expansion for math.tan
We can implement a polynomial approximation of math.tan by
decomposing to `math.sin` and `math.cos`. While it is not
technically a polynomial approximation it should be the most
straight forward approximation.

Reviewed By: jpienaar

Differential Revision: https://reviews.llvm.org/D144980
2023-03-01 01:13:54 +00:00
Kazu Hirata
f8f3db2756 Use APInt::count{l,r}_{zero,one} (NFC) 2023-02-19 22:04:47 -08:00
Kazu Hirata
cbde2124f1 Use APInt::popcount instead of APInt::countPopulation (NFC)
This is for consistency with the C++20-style bit manipulation
functions in <bit>.
2023-02-19 11:29:12 -08:00
Kazu Hirata
0a81ace004 [mlir] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<.  I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

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
2023-01-14 01:25:58 -08:00
Kazu Hirata
a1fe1f5f77 [mlir] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
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
2023-01-13 21:05:06 -08:00