| Age | Commit message (Collapse) | Author |
|---|
|
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
|
|
See https://github.com/llvm/llvm-project/pull/147168 for more info.
|
|
|
|
(#130782)
This is a follow-up to #127291, which added the benefit arg to lowerings
to intrinsics and libm.
In this change we add the benefit arg to the math approximation and
expansion lowerings, which allows users to establish a preferred order
among all three math lowerings, namely approximations, intrinsics and
libm.
Note that we're only updating the new API added in #126103. The legacy
one (`mlir::populateMathPolynomialApproximationPatterns`) is left
unmodified to encourage users to move out of it.
|
|
This patch adds the erfc op to the math dialect. It also does lowering
of the math.erfc op to libm calls. There is also a f32 polynomial
approximation for the function based on
https://stackoverflow.com/questions/35966695/vectorizable-implementation-of-complementary-error-function-erfcf
This is in turn based on
M. M. Shepherd and J. G. Laframboise, "Chebyshev Approximation of
(1+2x)exp(x^2)erfc x in 0 <= x < INF", Mathematics of Computation, Vol.
36, No. 153, January 1981, pp. 249-253.
The code has a ULP error less than 3, which was tested, and MLIR test
values were verified against the C implementation.
|
|
rewrites. (#126103)
The existing `mlir::populateMathPolynomialApproximationPatterns` is
coarse-grained and inflexible:
- It populates 2 distinct classes of patterns: (1) polynomial
approximations, (2) expansions of operands to f32.
- It does not offer knobs to select which math functions to apply the
rewrites to.
This PR adds finer-grained populate-patterns functions, which take a
predicate lambda allowing the caller to control which math functions to
apply rewrites to.
Signed-off-by: Benoit Jacob <jacob.benoit.1@gmail.com>
|
|
This patch disambiguates 0-rank vectors and scalars in
PolynomialApproximation. This fixes a bug in PolynomialApproximation
where 0-rank vectors would be treated as scalars and arguments would not
be broadcasted properly.
|
|
|
|
The polynomial approximation for asin is only good between [-9/16,
9/16]. Values beyond that range must be remapped to achieve good numeric
results. This is done by the equation below:
`arcsin(x) = PI/2 - arcsin(sqrt(1.0 - x*x))`
|
|
Adds the Polynomial Approximation for math.acos and math.asin op. Also,
it adds integration tests.
The Approximation has been borrowed from
https://stackoverflow.com/a/42683455
I added this script:
https://gist.github.com/pashu123/cd3e682b21a64ac306f650fb842a422b to
test 50 values between -1 and 1. The results are
https://gist.github.com/pashu123/8acb233bd045bacabfa8c992d4040465. It's
well within the bounds.
|
|
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.
|
|
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.
|
|
PolynomialApproximation.cpp (NFC)
|
|
Fixes windows build.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
while reusing implementations
Differential Revision: https://reviews.llvm.org/D145784
|
|
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
|
|
This is a follow-up to https://reviews.llvm.org/D140896, split into
several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
|
|
This revision refactors and cleans up a bunch of infra related to vector, shapes and indexing into more reusable APIs.
Differential Revision: https://reviews.llvm.org/D138501
|
|
This patch fixes:
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp:171:30:
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
mlir/lib/Dialect/Math/Transforms/PolynomialApproximation.cpp:283:30:
warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
|
|
f16 type support was missing in the math.erf op.
Reviewed By: ezhulenev
Differential Revision: https://reviews.llvm.org/D135770
|
|
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22.
Tested with:
`ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples`
and `bazel build --config=generic_clang @llvm-project//mlir:all`.
Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini
Differential Revision: https://reviews.llvm.org/D134762
|
|
To make room for introducing `math.absi`.
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D131325
|
|
Previously, NaNs would be dropped in favor of bounded values which was
strictly incorrect. Now the min/max operation propagate this
information. Not all uses of min/max need this, but the given change
will help protect future additions, and this prevents the need for an
additional cmpf and select operation to handle NaNs.
Differential Revision: https://reviews.llvm.org/D120020
|
|
Differential Revision: https://reviews.llvm.org/D119832
|
|
Differential Revision: https://reviews.llvm.org/D119822
|
|
Reuse the higher precision F32 approximation for the F16 one (by expanding and
truncating). This is partly RFC as I'm not sure what the expectations are here
(e.g., these are only for F32 and should not be expanded, that reusing
higher-precision ones for lower precision is undesirable due to increased
compute cost and only approximations per exact type is preferred, or this is
appropriate [at least as fallback] but we need to see how to make it more
generic across all the patterns here).
Differential Revision: https://reviews.llvm.org/D118968
|
|
Differential Revision: https://reviews.llvm.org/D119093
|
|
This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.
This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.
See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.
Differential Revision: https://reviews.llvm.org/D118654
|
|
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.
Differential Revision: https://reviews.llvm.org/D118648
|
|
This reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects.
Differential Revision: https://reviews.llvm.org/D118533
|
|
Differential Revision: https://reviews.llvm.org/D118536
|
|
PolynomialApproximation.cpp (NFC)
|
|
Implement a taylor series approximation for atan and add an atan2 lowering
that uses atan's appromation. This includes tests for edge cases and tests
for each quadrant.
Reviewed By: NatashaKnk
Differential Revision: https://reviews.llvm.org/D115682
|
|
Reviewed By: Mogball
Differential Revision: https://reviews.llvm.org/D116250
|
|
Differential Revision: https://reviews.llvm.org/D116248
|
|
Differential Revision: https://reviews.llvm.org/D116244
|
|
Reviewed By: ftynse
Differential Revision: https://reviews.llvm.org/D115956
|
|
|
|
[RFC](https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712)
Differential Revision: https://reviews.llvm.org/D114698
|
|
Using [1] for representing shape of a scalar is incorrect, and will break with vectors of size 1.
- remove redundant helper functions
- fix couple of style warnings
Reviewed By: cota
Differential Revision: https://reviews.llvm.org/D112764
|
|
ISA specific operation
Reviewed By: cota
Differential Revision: https://reviews.llvm.org/D112736
|
|
|
|
|
|
Polynomial approximation can be extented to support N-d vectors.
N-dimensional vectors are useful when vectorizing operations on N-dimensional
tiles. Before lowering to LLVM these vectors are usually unrolled or flattened
to 1-dimensional vectors.
Differential Revision: https://reviews.llvm.org/D112566
|
|
Add math.erf lowering to libm call.
Add math.erf polynomial approximation.
Reviewed By: silvas, ezhulenev
Differential Revision: https://reviews.llvm.org/D112200
|
