[mlir] Propagate NaNs in PolynomialApproximation

Previously, NaNs would be dropped in favor of bounded values which was
strictly incorrect. Now the min/max operation propagate this
information. Not

[mlir] Propagate NaNs in PolynomialApproximation

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

show more ...

[mlir][Math] Fix NaN handling in Exp approximation

Differential Revision: https://reviews.llvm.org/D119832

[mlir][Math] Fix NaN handling in ExpM1 approximation.

Differential Revision: https://reviews.llvm.org/D119822

[mlir][math] Expand coverage of atan2 expansion

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 a

[mlir][math] Expand coverage of atan2 expansion

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

show more ...

[mlir][NFC] Remove a few op builders that simply swap parameter order

Differential Revision: https://reviews.llvm.org/D119093

[mlir:Standard] Remove support for creating a `unit` ConstantOp

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into

[mlir:Standard] Remove support for creating a `unit` ConstantOp

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

show more ...

[mlir] Move SelectOp from Standard to Arithmetic

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

Differenti

[mlir] Move SelectOp from Standard to Arithmetic

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

show more ...

[mlir][vector][NFC] Split into IR, Transforms and Utils

This reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects.

Differential Revision: https://r

[mlir][vector][NFC] Split into IR, Transforms and Utils

This reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects.

Differential Revision: https://reviews.llvm.org/D118533

show more ...

[mlir] Silence warnings when building with MSVC

Differential Revision: https://reviews.llvm.org/D118536

Apply clang-tidy fixes for readability-identifier-naming in PolynomialApproximation.cpp (NFC)

[mlir] Add polynomial approximation for atan and atan2

Implement a taylor series approximation for atan and add an atan2 lowering
that uses atan's appromation. This includes tests for edge cases and

[mlir] Add polynomial approximation for atan and atan2

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

show more ...

Apply clang-tidy fixes for performance-unnecessary-value-param to MLIR (NFC)

Reviewed By: Mogball

Differential Revision: https://reviews.llvm.org/D116250

Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)

Differential Revision: https://reviews.llvm.org/D116248

Apply clang-tidy fixes for bugprone-argument-comment to MLIR (NFC)

Differential Revision: https://reviews.llvm.org/D116244

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

Differential Revision: https://reviews.llvm.org/D115956

[mlir] Update accessors prefixed form (NFC)

[mlir] Move bufferization-related passes to `bufferization` dialect.

[RFC](https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712)

Differential Revision: https://reviews.llvm

[mlir] Move bufferization-related passes to `bufferization` dialect.

[RFC](https://llvm.discourse.group/t/rfc-dialect-for-bufferization-related-ops/4712)

Differential Revision: https://reviews.llvm.org/D114698

show more ...

[mlir] MathApproximations: scalars shape must be 0-rank

Using [1] for representing shape of a scalar is incorrect, and will break with vectors of size 1.

- remove redundant helper functions
- fix c

[mlir] MathApproximations: scalars shape must be 0-rank

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

show more ...

[mlir] MathApproximations: unroll virtual vectors into hardware vectors for ISA specific operation

Reviewed By: cota

Differential Revision: https://reviews.llvm.org/D112736

[mlir] Use float literals to make Windows build happy.

[mlir] Update Erf approximation.

[mlir] Allow polynomial approximations for N-d vectors.

Polynomial approximation can be extented to support N-d vectors.
N-dimensional vectors are useful when vectorizing operations on N-dimensional

[mlir] Allow polynomial approximations for N-d vectors.

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

show more ...

[MLIR][Math] Add erf to math dialect

Add math.erf lowering to libm call.
Add math.erf polynomial approximation.

Reviewed By: silvas, ezhulenev

Differential Revision: https://reviews.llvm.org/D1122

[MLIR][Math] Add erf to math dialect

Add math.erf lowering to libm call.
Add math.erf polynomial approximation.

Reviewed By: silvas, ezhulenev

Differential Revision: https://reviews.llvm.org/D112200

show more ...

[mlir] Add polynomial approximation for vectorized math::Rsqrt

This patch adds a polynomial approximation that matches the
approximation in Eigen.

Note that the approximation only applies to vector

[mlir] Add polynomial approximation for vectorized math::Rsqrt

This patch adds a polynomial approximation that matches the
approximation in Eigen.

Note that the approximation only applies to vectorized inputs;
the scalar rsqrt is left unmodified.

The approximation is protected with a flag since it emits an AVX2
intrinsic (generated via the X86Vector). This is the only reasonably
clean way that I could find to generate the exact approximation that
I wanted (i.e. an identical one to Eigen's).

I considered two alternatives:

1. Introduce a Rsqrt intrinsic in LLVM, which doesn't exist yet.
I believe this is because there is no definition of Rsqrt that
all backends could agree on, since hardware instructions that
implement it have widely varying degrees of precision.
This is something that the standard could mandate, but Rsqrt is
not part of IEEE754, so I don't think this option is feasible.

2. Emit fdiv(1.0, sqrt) with fast math flags to allow reciprocal
transformations. Although portable, this doesn't allow us
to generate exactly the code we want; it is the LLVM backend,
and not MLIR, who controls what code is generated based on the
target CPU.

Reviewed By: ezhulenev

Differential Revision: https://reviews.llvm.org/D112192

show more ...

Avoid infinity arithmetics when computing exp approximations

Otherwise this can result a poison value on some platforms see https://bugs.llvm.org/show_bug.cgi?id=51204

Reviewed By: ezhulenev

Diffe

Avoid infinity arithmetics when computing exp approximations

Otherwise this can result a poison value on some platforms see https://bugs.llvm.org/show_bug.cgi?id=51204

Reviewed By: ezhulenev

Differential Revision: https://reviews.llvm.org/D112115

show more ...