[ValueTracking] Return `poison` for zero-sized types (#122647)

Return `poison` for zero-sized types in `isBitwiseValue`.

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is a

[NFC] Rename `Intrinsic::getDeclaration` to `getOrInsertDeclaration` (#111752)

Rename the function to reflect its correct behavior and to be consistent
with `Module::getOrInsertFunction`. This is also in preparation of
adding a new `Intrinsic::getDeclaration` that will have behavior similar
to `Module::getFunction` (i.e, just lookup, no creation).

show more ...

[llvm][unittests] Strip unneeded use of raw_string_ostream::str() (NFC)

Avoid excess layer of indirection.

[UnitTests] Convert a test to use opaque pointers (#102668)

[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] Restore isKnownNonZero parameter order. (#88873)

Prior to #85863, the required parameters of llvm::isKnownNonZero were
Value and DataLayout. After, they are Value, Depth, and Simpli

[ValueTracking] Restore isKnownNonZero parameter order. (#88873)

Prior to #85863, the required parameters of llvm::isKnownNonZero were
Value and DataLayout. After, they are Value, Depth, and SimplifyQuery,
where SimplifyQuery is implicitly constructible from DataLayout. The
change to move Depth before SimplifyQuery needed callers to be updated
unnecessarily, and as commented in #85863, we actually want Depth to be
after SimplifyQuery anyway so that it can be defaulted and the caller
does not need to specify it.

show more ...

ValueTracking: Treat poison more aggressively in computeKnownFPClass (#87990)

Assume no valid values, and the sign bit is 0.

[ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (#85863)

This patch converts `isKnownNonZero` to use SimplifyQuery. Then we can
use the context information from `DomCondCache`.

Fix

[ValueTracking] Convert `isKnownNonZero` to use SimplifyQuery (#85863)

This patch converts `isKnownNonZero` to use SimplifyQuery. Then we can
use the context information from `DomCondCache`.

Fixes https://github.com/llvm/llvm-project/issues/85823.
Alive2: https://alive2.llvm.org/ce/z/QUvHVj

show more ...

ValueTracking: Handle ConstantAggregateZero in computeKnownFPClass

[ValueTracking] Fix KnownBits conflict for calls (range vs returned) (#84353)

If a function only exits for certain input values we can still derive
that an argument is "returned". We can also deriv

[ValueTracking] Fix KnownBits conflict for calls (range vs returned) (#84353)

If a function only exits for certain input values we can still derive
that an argument is "returned". We can also derive range metadata that
describe the possible value range returned by the function. However, it
turns out that those two analyses can result in conflicting information.

Example:
declare i16 @foo(i16 returned)
...
%A = call i16 @foo(i16 4095), !range !{i16 32, i16 33}

To avoid "Bits known to be one AND zero?" assertion failures we know
make sure to discard the known bits for this kind of scenario.

show more ...

[ValueTracking] Handle more integer intrinsics in `propagatesPoison` (#82749)

This patch extends `propagatesPoison` to handle more integer intrinsics.
It will turn more logical ands/ors into bitwis

[ValueTracking] Handle more integer intrinsics in `propagatesPoison` (#82749)

This patch extends `propagatesPoison` to handle more integer intrinsics.
It will turn more logical ands/ors into bitwise ands/ors.

See also https://reviews.llvm.org/D99671.

show more ...

ValueTracking: Recognize fcmp ole/ugt with inf as a class test (#79095)

These were missed and hopefully avoids assertions when
dc3faf0ed0e3f1ea9e435a006167d9649f865da1 is recommitted.

[ValueTracking] Shufflevector produces poison rather than undef

Shufflevector semantics have changed so that poison mask elements
return poison rather than undef. Reflect this in the
canCreateUndefO

[ValueTracking] Shufflevector produces poison rather than undef

Shufflevector semantics have changed so that poison mask elements
return poison rather than undef. Reflect this in the
canCreateUndefOrPoison() implementation.

show more ...

[InstCombine] Check isGuaranteedNotToBeUndef in haveNoCommonBitsSetSpecialCases. (#74390)

It's not safe for InstCombine to add disjoint metadata when converting
Add to Or otherwise.

I've added n

[InstCombine] Check isGuaranteedNotToBeUndef in haveNoCommonBitsSetSpecialCases. (#74390)

It's not safe for InstCombine to add disjoint metadata when converting
Add to Or otherwise.

I've added noundef attribute to preserve existing test behavior.

show more ...

ValueTracking: Handle compare gt to -inf in class identification (#72086)

This apparently shows up somewhere in chromium. We also are missing a
canonicalization to an equality compare with inf.

ValueTracking: Use fcAllFlags for unknown value (#66393)

In the failure case we return null, which callers are checking. We were
also returning an fcNone which was unused. It's more consistent to

ValueTracking: Use fcAllFlags for unknown value (#66393)

In the failure case we return null, which callers are checking. We were
also returning an fcNone which was unused. It's more consistent to
return fcAllFlags as any possible value, such that the value is always
directly usable without checking the returned value.

show more ...

[ValueTracking] Don't handle ptrtoint with mismatches sizes

When processing assumes, we also handle assumes on ptrtoint of the
value. In canonical IR, these will have the same size as the value.
How

[ValueTracking] Don't handle ptrtoint with mismatches sizes

When processing assumes, we also handle assumes on ptrtoint of the
value. In canonical IR, these will have the same size as the value.
However, in non-canonical IR there may be an implicit zext or
trunc, which results in a bit width mismatch. We currently handle
this by adjusting bitwidth everywhere, but this is fragile and I'm
pretty sure that the way we do this is incorrect for some predicates,
because we effectively end up commuting an ext/trunc and an icmp.

Instead, add an m_PtrToIntSameSize() matcher that will only handle
bitwidth preserving cases. For the bitwidth-changing cases, wait
until they have been canonicalized.

The original handling for this was added purely to prevent crashes
in an earlier implementation which failed to account for this
entirely.

show more ...

ValueTracking: Handle !absolute_symbol in computeKnownBits

Use a unit test since I don't see any existing uses try to make use of
the high bits of a pointer.

This will also assert if the metadata t

ValueTracking: Handle !absolute_symbol in computeKnownBits

Use a unit test since I don't see any existing uses try to make use of
the high bits of a pointer.

This will also assert if the metadata type doesn't match the pointer
width, but I consider that a defect in the verifier and shouldn't be
handled.

AMDGPU allocates LDS globals by assigning !absolute_symbol with the
final fixed address. Tracking the high bits are 0 may help with
addressing mode matching.

show more ...

ValueTracking: Ignore -0 for nsz sqrt with UseInstrInfo in computeKnownFPClass

This avoids a regression when SignBitMustBeZero is moved to computeKnownFPClass.

ValueTracking: Handle compare to nan and -inf constants in fcmpToClassTest

This will help enable a cleanup of simplifyFCmpInst

[KnownBits] Return zero instead of unknown for always poison shifts

For always poison shifts, any KnownBits return value is valid.
Currently we return unknown, but returning zero is generally more
p

[KnownBits] Return zero instead of unknown for always poison shifts

For always poison shifts, any KnownBits return value is valid.
Currently we return unknown, but returning zero is generally more
profitable. We had some code in ValueTracking that tried to do this,
but was actually dead code.

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

show more ...

Reapply "ValueTracking: Handle phi in computeKnownFPClass"

This reverts commit e13f88d1ff5234946af6349a9a7cf56fcb6c040e.

Fix off by one recursion limit check.

Revert "ValueTracking: Handle phi in computeKnownFPClass"

This reverts commit cac9e427eb1ff3dabda8ac08968b998c3bc5ab47.

Causing crashes in lencod

ValueTracking: Handle phi in computeKnownFPClass

Doesn't try the all the tricks computeKnownBits does.

ValueTracking: Implement computeKnownFPClass for sqrt

Could be slightly smarter in cases that are probably uninteresting.