[ValueTracking] allow vector types in isImpliedCondition()

The matching of constants assumed integers, but we can handle
splat vector constants seamlessly with m_APInt.

[ValueTracking] add test for isImpliedCondition with vector types; NFC

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDi

[ConstExpr] Remove div/rem constant expressions

D128820 stopped creating div/rem constant expressions by default;
this patch removes support for them entirely.

The getUDiv(), getExactUDiv(), getSDiv(), getExactSDiv(), getURem()
and getSRem() on ConstantExpr are removed, and ConstantExpr::get()
now only accepts binary operators for which
ConstantExpr::isSupportedBinOp() returns true. Uses of these methods
may be replaced either by corresponding IRBuilder methods, or
ConstantFoldBinaryOpOperands (if a constant result is required).

On the C API side, LLVMConstUDiv, LLVMConstExactUDiv, LLVMConstSDiv,
LLVMConstExactSDiv, LLVMConstURem and LLVMConstSRem are removed and
corresponding LLVMBuild methods should be used.

Importantly, this also means that constant expressions can no longer
trap! This patch still keeps the canTrap() method to minimize diff --
I plan to drop it in a separate NFC patch.

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

show more ...

[ValueTracking] Checking haveNoCommonBitsSet for (x & y) and ~(x | y)

This one tries to fix:
https://github.com/llvm/llvm-project/issues/53357.

Simply, this one would check (x & y) and ~(x | y) in

[ValueTracking] Checking haveNoCommonBitsSet for (x & y) and ~(x | y)

This one tries to fix:
https://github.com/llvm/llvm-project/issues/53357.

Simply, this one would check (x & y) and ~(x | y) in
haveNoCommonBitsSet. Since they shouldn't have common bits (we could
traverse the case by enumerating), and we could convert this one to (x &
y) | ~(x | y) . Then the compiler could handle it in
InstCombineAndOrXor.
Further more, since ((x & y) + (~x & ~y)) would be converted to ((x & y)
+ ~(x | y)), this patch would fix it too.

https://alive2.llvm.org/ce/z/qsKzRS

Reviewed By: spatel, xbolva00, RKSimon, lebedev.ri

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

show more ...

[NFC] Precommit for PR53357

Due to there are other required changes in
https://reviews.llvm.org/D118094, precommit these changes to ease
reviewing. Including:
- Remove *_thwart tests.
- Remove test

[NFC] Precommit for PR53357

Due to there are other required changes in
https://reviews.llvm.org/D118094, precommit these changes to ease
reviewing. Including:
- Remove *_thwart tests.
- Remove test for (x & y) + (~x & ~y)
- Fix incorrect uniitest committeed before

show more ...

[NFC] [ValueTracking] Add unittest for haveNoCommonBitsSet

[Analysis] allow caller to choose signed/unsigned when computing constant range

We should not lose analysis precision if an 'add' has both no-wrap
flags (nsw and nuw) compared to just one or the oth

[Analysis] allow caller to choose signed/unsigned when computing constant range

We should not lose analysis precision if an 'add' has both no-wrap
flags (nsw and nuw) compared to just one or the other.

This patch is modeled on a similar construct that was added with
D59386.

I don't think it is possible to expose a problem with an unsigned
compare because of the way this was coded (nuw is handled first).

InstCombine has an assert that fires with the example from:
https://github.com/llvm/llvm-project/issues/52884
...because it was expecting InstSimplify to handle this kind of
pattern with an smax.

Fixes #52884

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

show more ...

[Analysis] fix cast in ValueTracking to allow constant expression

The test would crash because a non-instruction negate op made it in here.

Fixes #51506

[Analysis] Fix another issue when querying vscale attributes on functions

There are several places in the code that are currently broken where
we assume an Instruction is always a member of a BasicB

[Analysis] Fix another issue when querying vscale attributes on functions

There are several places in the code that are currently broken where
we assume an Instruction is always a member of a BasicBlock that
lives in a Function. This is a problem specifically when
attempting to get the vscale_range attribute. This patch adds checks
that an Instruction's parent also has a parent!

I've added a test for a function-less @llvm.vscale intrinsic call here:

unittests/Analysis/ValueTrackingTest.cpp

show more ...

[Analysis] Fix issues when querying vscale attributes on functions

There are several places in the code that are currently broken as
they assume an Instruction always has a parent Function when
atte

[Analysis] Fix issues when querying vscale attributes on functions

There are several places in the code that are currently broken as
they assume an Instruction always has a parent Function when
attempting to get the vscale_range attribute. This patch adds checks
that an Instruction has a parent.

I've added a test for a parentless @llvm.vscale intrinsic call here:

unittests/Analysis/ValueTrackingTest.cpp

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

show more ...

[ValueTracking,VectorCombine] Allow passing DT to computeConstantRange.

isValidAssumeForContext can provide better results with access to the
dominator tree in some cases. This patch adjusts compute

[ValueTracking,VectorCombine] Allow passing DT to computeConstantRange.

isValidAssumeForContext can provide better results with access to the
dominator tree in some cases. This patch adjusts computeConstantRange to
allow passing through a dominator tree.

The use VectorCombine is updated to pass through the DT to enable
additional scalarization.

Note that similar APIs like computeKnownBits already accept optional dominator
tree arguments.

Reviewed By: lebedev.ri

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

show more ...

[value-tracking] see through returned attribute.

Reviewed By: vitalybuka

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

[ValueTracking] Fix computeConstantRange to use "may" instead of "always" semantics for llvm.assume

ValueTracking should allow for value ranges that may satisfy
llvm.assume, instead of restricting t

[ValueTracking] Fix computeConstantRange to use "may" instead of "always" semantics for llvm.assume

ValueTracking should allow for value ranges that may satisfy
llvm.assume, instead of restricting the ranges only to values that
will always satisfy the condition.

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

show more ...

Update @llvm.powi to handle different int sizes for the exponent

This can be seen as a follow up to commit 0ee439b705e82a4fe20e2,
that changed the second argument of __powidf2, __powisf2 and
__powit

Update @llvm.powi to handle different int sizes for the exponent

This can be seen as a follow up to commit 0ee439b705e82a4fe20e2,
that changed the second argument of __powidf2, __powisf2 and
__powitf2 in compiler-rt from si_int to int. That was to align with
how those runtimes are defined in libgcc.
One thing that seem to have been missing in that patch was to make
sure that the rest of LLVM also handle that the argument now depends
on the size of int (not using the si_int machine mode for 32-bit).
When using __builtin_powi for a target with 16-bit int clang crashed.
And when emitting libcalls to those rtlib functions, typically when
lowering @llvm.powi), the backend would always prepare the exponent
argument as an i32 which caused miscompiles when the rtlib was
compiled with 16-bit int.

The solution used here is to use an overloaded type for the second
argument in @llvm.powi. This way clang can use the "correct" type
when lowering __builtin_powi, and then later when emitting the libcall
it is assumed that the type used in @llvm.powi matches the rtlib
function.

One thing that needed some extra attention was that when vectorizing
calls several passes did not support that several arguments could
be overloaded in the intrinsics. This patch allows overload of a
scalar operand by adding hasVectorInstrinsicOverloadedScalarOpd, with
an entry for powi.

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

show more ...

[ValueTracking] add FP intrinsics to test for propagatesPoison; NFC

I'm not sure what behavior we want if the FP environment is
not default (also not sure if there's a way to enumerate
the full list

[ValueTracking] add FP intrinsics to test for propagatesPoison; NFC

I'm not sure what behavior we want if the FP environment is
not default (also not sure if there's a way to enumerate
the full list of intrinsics programmatically), but currently
these are all defaulting to 'false' (doesn't propagate).

show more ...

[ValueTracking] add tests for propagatesPoison with FP ops; NFC

Verify that this matches the behavior in InstSimplify:
D104383 / ce95200b7942

We still need to add code/tests for FP intrinsics.

ValueTrackingTest.cpp - Pass DataLayout by reference. NFCI.

Bump googletest to 1.10.0

[ValueTracking] match negative-stepping non-zero recurrence

This is pulled out of D100408.

This avoids a regression that would be exposed by making the
calling code from InstSimplify more efficient.

[ValueTracking] add unit test for isKnownNonZero(); NFC

We call various value tracking APIs from within -instsimplify,
so I don't think this is visible in a larger test.

[ValueTracking] Add with.overflow intrinsics to poison analysis functions

This is a patch teaching ValueTracking that `s/u*.with.overflow` intrinsics do not
create undef/poison and they propagate po

[ValueTracking] Add with.overflow intrinsics to poison analysis functions

This is a patch teaching ValueTracking that `s/u*.with.overflow` intrinsics do not
create undef/poison and they propagate poison.
I couldn't write a nice example like the one with ctpop; ValueTrackingTest.cpp were simply updated
to check these instead.
This patch helps reducing regression while fixing https://llvm.org/pr49688 .

Reviewed By: nikic

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

show more ...

[ValueTracking] Don't assume readonly function will return

This is similar to D94106, but for the
isGuaranteedToTransferExecutionToSuccessor() helper. We should not
assume that readonly functions wi

[ValueTracking] Don't assume readonly function will return

This is similar to D94106, but for the
isGuaranteedToTransferExecutionToSuccessor() helper. We should not
assume that readonly functions will return, as this is only true for
mustprogress functions (in which case we already infer willreturn).
As with the DCE change, for now continue assuming that readonly
intrinsics will return, as not all target intrinsics have been
annotated yet.

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

show more ...

[ValueTracking] Strengthen impliesPoison reasoning

Split impliesPoison into two recursive walks, one over V, the
other over ValAssumedPoison. This allows us to reason about poison
implications in a

[ValueTracking] Strengthen impliesPoison reasoning

Split impliesPoison into two recursive walks, one over V, the
other over ValAssumedPoison. This allows us to reason about poison
implications in a number of additional cases that are important
in practice. This is a generalized form of D94859, which handles
the cmp to cmp implication in particular.

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

show more ...

[ValueTracking] Fix one s/dyn_cast/dyn_cast_or_null/

Handle if Constant::getAggregateElement() returns nullptr in
canCreateUndefOrPoison().

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

[Constant] Add containsPoisonElement

This patch

- Adds containsPoisonElement that checks existence of poison in constant vector elements,
- Renames containsUndefElement to containsUndefOrPoisonElem

[Constant] Add containsPoisonElement

This patch

- Adds containsPoisonElement that checks existence of poison in constant vector elements,
- Renames containsUndefElement to containsUndefOrPoisonElement to clarify its behavior & updates its uses properly

With this patch, isGuaranteedNotToBeUndefOrPoison's tests w.r.t constant vectors are added because its analysis is improved.

Thanks!

Reviewed By: nikic

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

show more ...