[LLVM][IR] Use splat syntax when printing ConstantExpr based splats. (#116856)

This brings the printing of scalable vector constant splats inline with
their fixed length counterparts.

[LLVM][IR] Use splat syntax when printing Constant[Data]Vector. (#112548)

[ValueTracking] mul nuw nsw with factor sgt 1 is non-negative (#110803)

Proof: https://alive2.llvm.org/ce/z/bC0eJf

[InstCombine] Replace all dominated uses of condition with constants (#105510)

This patch replaces all dominated uses of condition with true/false to
improve context-sensitive optimizations. It eli

[InstCombine] Replace all dominated uses of condition with constants (#105510)

This patch replaces all dominated uses of condition with true/false to
improve context-sensitive optimizations. It eliminates a bunch of
branches in llvm-opt-benchmark.

As a side effect, it may introduce new phi nodes in some corner cases.
See the following case:
```
define i1 @test(i1 %cmp, i1 %cond) {
entry:
br i1 %cond, label %bb1, label %bb2
bb1:
br i1 %cmp, label %if.then, label %if.else
if.then:
br %bb2
if.else:
br %bb2
bb2:
%res = phi i1 [%cmp, %entry], [%cmp, %if.then], [%cmp, %if.else]
ret i1 %res
}
```
It will be simplified into:
```
define i1 @test(i1 %cmp, i1 %cond) {
entry:
br i1 %cond, label %bb1, label %bb2
bb1:
br i1 %cmp, label %if.then, label %if.else
if.then:
br %bb2
if.else:
br %bb2
bb2:
%res = phi i1 [%cmp, %entry], [true, %if.then], [false, %if.else]
ret i1 %res
}
```

I am planning to fix this in late pipeline/CGP since this problem exists
before the patch.

show more ...

[InstCombine] Remove some of the complexity-based canonicalization (#91185)

The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be can

[InstCombine] Remove some of the complexity-based canonicalization (#91185)

The idea behind this canonicalization is that it allows us to handle less
patterns, because we know that some will be canonicalized away. This is
indeed very useful to e.g. know that constants are always on the right.

However, this is only useful if the canonicalization is actually
reliable. This is the case for constants, but not for arguments: Moving
these to the right makes it look like the "more complex" expression is
guaranteed to be on the left, but this is not actually the case in
practice. It fails as soon as you replace the argument with another
instruction.

The end result is that it looks like things correctly work in tests,
while they actually don't. We use the "thwart complexity-based
canonicalization" trick to handle this in tests, but it's often a
challenge for new contributors to get this right, and based on the
regressions this PR originally exposed, we clearly don't get this right
in many cases.

For this reason, I think that it's better to remove this complexity
canonicalization. It will make it much easier to write tests for
commuted cases and make sure that they are handled.

show more ...

Reapply [InstCombine] Fix context for multi-use demanded bits simplification

Repplied with a clang test fix.

-----

When simplifying a multi-use root value, the demanded bits were
reset to full, bu

Reapply [InstCombine] Fix context for multi-use demanded bits simplification

Repplied with a clang test fix.

-----

When simplifying a multi-use root value, the demanded bits were
reset to full, but we also need to reset the context instruction.
To make this convenient (without requiring by-value passing of
SimplifyQuery), move the logic that handles constants and
dispatches to SimplifyDemandedUseBits/SimplifyMultipleUseDemandedBits
into SimplifyDemandedBits. The SimplifyDemandedInstructionBits
caller starts with full demanded bits and an appropriate context
anyway.

The different context instruction does mean that the ephemeral
value protection no longer triggers in some cases, as the changes
to assume tests show.

An alternative, which I will explore in a followup, is to always
use SimplifyMultipleUseDemandedBits() -- the previous root special
case is only really intended for SimplifyDemandedInstructionBits(),
which now no longer shares this code path.

Fixes https://github.com/llvm/llvm-project/issues/97330.

show more ...

Revert "[InstCombine] Fix context for multi-use demanded bits simplification"

This reverts commit b558ac0eef57a3737b1e27844115fa91e0b32582.

This breaks a clang test, reverting for now.

[InstCombine] Fix context for multi-use demanded bits simplification

When simplifying a multi-use root value, the demanded bits were
reset to full, but we also need to reset the context extract. To

[InstCombine] Fix context for multi-use demanded bits simplification

When simplifying a multi-use root value, the demanded bits were
reset to full, but we also need to reset the context extract. To
make this convenient (without requiring by-value passing of
SimplifyQuery), move the logic that that handles constants and
dispatches to SimplifyDemandedUseBits/SimplifyMultipleUseDemandedBits
into SimplifyDemandedBits. The SimplifyDemandedInstructionBits
caller starts with full demanded bits and an appropriate context
anyway.

The different context instruction does mean that the ephemeral
value protection no longer triggers in some cases, as the changes
to assume tests show.

An alternative, which I will explore in a followup, is to always
use SimplifyMultipleUseDemandedBits() -- the previous root special
case is only really intended for SimplifyDemandedInstructionBits(),
which now no longer shares this code path.

Fixes https://github.com/llvm/llvm-project/issues/97330.

show more ...

[InstCombine] Add test for #97330 (NFC)

[InstCombine] Pass SimplifyQuery to SimplifyDemandedBits()

This will enable calling SimplifyDemandedBits() with a SimplifyQuery
that has CondContext set in the future.

Additionally this also margin

[InstCombine] Pass SimplifyQuery to SimplifyDemandedBits()

This will enable calling SimplifyDemandedBits() with a SimplifyQuery
that has CondContext set in the future.

Additionally this also marginally strengthens the analysis by
retaining the original context instruction for one-use chains.

show more ...

[InstCombine] Add test for SimplifyDemanded context (NFC)

[ValueTracking] Fix incorrect inferrence about the signbit of sqrt (#92510)

According to IEEE Std 754-2019, `sqrt` returns nan when the input is
negative (except for -0). In this case, we cannot ma

[ValueTracking] Fix incorrect inferrence about the signbit of sqrt (#92510)

According to IEEE Std 754-2019, `sqrt` returns nan when the input is
negative (except for -0). In this case, we cannot make assumptions about
sign bit of the result.

Fixes https://github.com/llvm/llvm-project/issues/92217

show more ...

[ValueTracking] Compute knownbits from `(icmp upred (add/sub nuw X, Y), C)`

`(icmp ule/ult (add nuw X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce

[ValueTracking] Compute knownbits from `(icmp upred (add/sub nuw X, Y), C)`

`(icmp ule/ult (add nuw X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce leading zeros in `X`/`Y`.

`(icmp uge/ugt (sub nuw X, Y), C)` implies `(icmp uge/uge X, C)` . We
can use this to deduce leading ones in `X`.

Proofs: https://alive2.llvm.org/ce/z/sc5k22

Closes #87180

show more ...

[ValueTracking] Add tests for computing knownbits from `(icmp upred (add/sub nuw X, Y), C)`; NFC

[ValueTracking] Fix assertion failure when `computeKnownFPClass` returns fcNone (#92355)

Fixes
https://github.com/llvm/llvm-project/pull/92084#issuecomment-2114083188.

Reland "[ValueTracking] Compute knownbits from known fp classes" (#92084)

This patch relands https://github.com/llvm/llvm-project/pull/86409.

I mistakenly thought that `Known.makeNegative()` clea

Reland "[ValueTracking] Compute knownbits from known fp classes" (#92084)

This patch relands https://github.com/llvm/llvm-project/pull/86409.

I mistakenly thought that `Known.makeNegative()` clears the sign bit of
`Known.Zero`. This patch fixes the assertion failure by explicitly
clearing the sign bit.

show more ...

Revert "[ValueTracking] Compute knownbits from known fp classes (#86409)"

This reverts commit d03a1a6e5838c7c2c0836d71507dfdf7840ade49.

This change caused failed assertions, see
https://github.com/

Revert "[ValueTracking] Compute knownbits from known fp classes (#86409)"

This reverts commit d03a1a6e5838c7c2c0836d71507dfdf7840ade49.

This change caused failed assertions, see
https://github.com/llvm/llvm-project/pull/86409#issuecomment-2109469845
for details.

show more ...

[ValueTracking] Compute knownbits from known fp classes (#86409)

This patch calculates knownbits from fp instructions/dominating fcmp
conditions. It will enable more optimizations with signbit idio

[ValueTracking] Compute knownbits from known fp classes (#86409)

This patch calculates knownbits from fp instructions/dominating fcmp
conditions. It will enable more optimizations with signbit idioms.

show more ...

[InstCombine] Update `vector_reduce_and` tests to actually use `llvm.vector.reduce.and`; NFC

[ValueTracking] Implement `computeKnownBits` for `llvm.vector.reduce.xor`

[ValueTracking] Add tests for `computeKnownBits` of `llvm.vector.reduce.xor`; NFC

[ValueTracking] Implement `computeKnownBits` for `llvm.vector.reduce.{or,and}`

[ValueTracking] Add tests for `computeKnownBits` of `llvm.vector.reduce.{or,and}`; NFC

[ValueTracking] compute knownbits from `(icmp upred X (and/or X, Y))`; NFC

`(icmp uge/ugt (and X, Y), C)` implies both `(icmp uge/ugt X, C)` and
`(icmp uge/ugt Y, C)`. We can use this to deduce lead

[ValueTracking] compute knownbits from `(icmp upred X (and/or X, Y))`; NFC

`(icmp uge/ugt (and X, Y), C)` implies both `(icmp uge/ugt X, C)` and
`(icmp uge/ugt Y, C)`. We can use this to deduce leading ones in `X`.

`(icmp ule/ult (or X, Y), C)` implies both `(icmp ule/ult X, C)` and
`(icmp ule/ult Y, C)`. We can use this to deduce leading zeros in `X`.

Closes #86059

show more ...

[ValueTracking] Add tests for computing knownbits from `(icmp upred X (and/or X, Y))`; NFC