[InstCombine] Make fptrunc combine use intersection of fast math flags (#118808)

These combines involve swapping the fptrunc with its operand, and using
the intersection of fast math flags is the s

[InstCombine] Make fptrunc combine use intersection of fast math flags (#118808)

These combines involve swapping the fptrunc with its operand, and using
the intersection of fast math flags is the safest option as e.g. if we
have (fptrunc (fneg ninf x)) then (fneg ninf (fptrunc x)) will not be
correct as if x is a not within the range of the destination type the
result of (fptrunc x) will be inf.

show more ...

[IR] Allow fast math flags on fptrunc and fpext (#115894)

This consists of:
* Make these instructions part of FPMathOperator.
* Adjust bitcode/ir readers/writers to expect fast math flags on thes

[IR] Allow fast math flags on fptrunc and fpext (#115894)

This consists of:
* Make these instructions part of FPMathOperator.
* Adjust bitcode/ir readers/writers to expect fast math flags on these
instructions.
* Make IRBuilder set the fast math flags on these instructions.
* Update langref and release notes.
* Update a bunch of tests. Some of these are due to InstCombineCasts
incorrectly adding fast math flags to fptrunc, which will be fixed in a
later patch.

show more ...

[PatternMatch] Do not accept undef elements in m_AllOnes() and friends (#88217)

Change all the cstval_pred_ty based PatternMatch helpers (things like
m_AllOnes and m_Zero) to only allow poison elem

[PatternMatch] Do not accept undef elements in m_AllOnes() and friends (#88217)

Change all the cstval_pred_ty based PatternMatch helpers (things like
m_AllOnes and m_Zero) to only allow poison elements inside vector
splats, not undef elements.

Historically, we used to represent non-demanded elements in vectors
using undef. Nowadays, we use poison instead. As such, I believe that
support for undef in vector splats is no longer useful.

At the same time, while poison splat elements are pretty much always
safe to ignore, this is not generally the case for undef elements. We
have existing miscompiles in our tests due to this (see the
masked-merge-*.ll tests changed here) and it's easy to miss such cases
in the future, now that we write tests using poison instead of undef
elements.

I think overall, keeping support for undef elements no longer makes
sense, and we should drop it. Once this is done consistently, I think we
may also consider allowing poison in m_APInt by default, as doing that
change is much less risky than doing the same with undef.

This change involves a substantial amount of test changes. For most
tests, I've just replaced undef with poison, as I don't think there is
value in retaining both. For some tests (where the distinction between
undef and poison is important), I've duplicated tests.

show more ...

[InstCombine] Add canonicalization of `sitofp` -> `uitofp nneg`

This is essentially the same as #82404 but has the `nneg` flag which
allows the backend to reliably undo the transform.

Closes #88299

[InstCombine] Fold `fmul X, -0.0` into `copysign(0.0, -X)` (#85772)

`fneg + copysign` is better than fmul for analysis/codegen.
godbolt: https://godbolt.org/z/eEs6dGd1G
Alive2: https://alive2.llvm

[InstCombine] Fold `fmul X, -0.0` into `copysign(0.0, -X)` (#85772)

`fneg + copysign` is better than fmul for analysis/codegen.
godbolt: https://godbolt.org/z/eEs6dGd1G
Alive2: https://alive2.llvm.org/ce/z/K3M5BA

show more ...

Revert "[InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0`"

This reverts commit d80d5b923c6f611590a12543bdb33e0c16044d44.

It wasn't a particularly important transform to begin with

Revert "[InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0`"

This reverts commit d80d5b923c6f611590a12543bdb33e0c16044d44.

It wasn't a particularly important transform to begin with and caused
some codegen regressions on targets that prefer `sitofp` so dropping.

Might re-visit along with adding `nneg` flag to `uitofp` so its easily
reversable for the backend.

show more ...

[InstCombine] Fold `fpto{s|u}i non-norm` to zero (#85569)

This patch enables more optimization after canonicalizing `fmul X, 0.0`
into a copysign.
I decide to implement this fold in InstCombine be

[InstCombine] Fold `fpto{s|u}i non-norm` to zero (#85569)

This patch enables more optimization after canonicalizing `fmul X, 0.0`
into a copysign.
I decide to implement this fold in InstCombine because
`computeKnownFPClass` may be expensive.

Alive2: https://alive2.llvm.org/ce/z/ASM8tQ

show more ...

[InstCombine] Canonicalize `(sitofp x)` -> `(uitofp x)` if `x >= 0`

Just a standard canonicalization.

Proofs: https://alive2.llvm.org/ce/z/9W4VFm

Closes #82404

[InstCombine] Use known bits to determine exact int->fp cast

Reviewed By: spatel, nikic

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

[InstCombine] add tests for FP casts; NFC

[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC

Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.

Differential Revision: https://r

[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC

Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.

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

show more ...

Remove BinaryOperator::CreateFNeg

Use UnaryOperator::CreateFNeg instead.

Summary:
With the introduction of the native fneg instruction, the
fsub -0.0, %x idiom is obsolete. This patch makes LLVM
em

Remove BinaryOperator::CreateFNeg

Use UnaryOperator::CreateFNeg instead.

Summary:
With the introduction of the native fneg instruction, the
fsub -0.0, %x idiom is obsolete. This patch makes LLVM
emit fneg instead of the idiom in all places.

Reviewed By: cameron.mcinally

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

show more ...

[InstCombine] Update fptrunc (fneg x)) -> (fneg (fptrunc x) for unary FNeg

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

llvm-svn: 363080

[NFC][InstCombine] Add unary FNeg tests to fpcast.ll and fpextend.ll

llvm-svn: 361973

Revert "Temporarily Revert "Add basic loop fusion pass.""

The reversion apparently deleted the test/Transforms directory.

Will be re-reverting again.

llvm-svn: 358552

[FPEnv] Last BinaryOperator::isFNeg(...) to m_FNeg(...) changes

Replacing BinaryOperator::isFNeg(...) to avoid regressions when we
separate FNeg from the FSub IR instruction.

Differential Revision:

[FPEnv] Last BinaryOperator::isFNeg(...) to m_FNeg(...) changes

Replacing BinaryOperator::isFNeg(...) to avoid regressions when we
separate FNeg from the FSub IR instruction.

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

llvm-svn: 345295

show more ...

[InstCombine] add test for fptrunc with vector with undef elt; NFC

This should be fixed with D53650.

llvm-svn: 345206

[InstCombine] don't change the size of a select if it would mismatch its condition operands' sizes

Don't always:
cast (select (cmp x, y), z, C) --> select (cmp x, y), (cast z), C'

This is something

[InstCombine] don't change the size of a select if it would mismatch its condition operands' sizes

Don't always:
cast (select (cmp x, y), z, C) --> select (cmp x, y), (cast z), C'

This is something that came up as far back as D26556, and I lost track of it.
I suspect that this transform is part of the underlying problem that is
inspiring some of the recent proposals that seek to match larger patterns
that include a cast op. Even if that's not true, this transform causes
problems for codegen (particularly with vector types).

A transform to actively match the size of cmp and select operand sizes should
follow. This patch just removes the harmful canonicalization in the other
direction.

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

llvm-svn: 333611

show more ...

[InstCombine] regenerate checks; NFC

llvm-svn: 332894

[IR] fptrunc-of-fptrunc isn't an EliminableCastPair.

Double and single rounding can produce different results.
This is the IR counterpart to r228911.

llvm-svn: 238531

Fix another infinite loop in InstCombine

Summary:
InstCombine infinite-loops for the testcase added
It is because InstCombine is generating instructions that can be
optimized by itself. Fix by not o

Fix another infinite loop in InstCombine

Summary:
InstCombine infinite-loops for the testcase added
It is because InstCombine is generating instructions that can be
optimized by itself. Fix by not optimizing frem if the optimized
type is the same as original type.
rdar://problem/19150820

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D6634

llvm-svn: 224097

show more ...

InstCombine: Fix another infinite loop caused by visitFPTrunc

We would attempt to replace an frem's operand with the same operand.
This would cause InstCombine to think real work was done, causing
I

InstCombine: Fix another infinite loop caused by visitFPTrunc

We would attempt to replace an frem's operand with the same operand.
This would cause InstCombine to think real work was done, causing
InstCombine to enter an infinite loop.

This fixes the second part of PR21576.

llvm-svn: 222265

show more ...

Revert "Revert r222040 because of bot failure."

This reverts commit r222203, reverting r222040 didn't end up turning the
bot green.

llvm-svn: 222261

Revert r222040 because of bot failure.

http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/
Hopefully, bot will be green.

llvm-svn: 222203

InstCombine: Fix infinite loop caused by visitFPTrunc

We would attempt to replace a fptrunc of an frem with an identical
fptrunc. This would cause the new fptrunc to be added to the worklist.
Of co

InstCombine: Fix infinite loop caused by visitFPTrunc

We would attempt to replace a fptrunc of an frem with an identical
fptrunc. This would cause the new fptrunc to be added to the worklist.
Of course, this results in an infinite loop because we will keep
visiting the newly created fptruncs.

This fixes PR21576.

llvm-svn: 222040

show more ...