[SCCP] Infer nuw for gep nusw with non-negative offsets (#118819)

If the GEP is nusw/inbounds and has all-non-negative offsets infer nuw
as well.

This doesn't have measurable compile-time impact

[SCCP] Infer nuw for gep nusw with non-negative offsets (#118819)

If the GEP is nusw/inbounds and has all-non-negative offsets infer nuw
as well.

This doesn't have measurable compile-time impact.

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

show more ...

[SCCP] Handle llvm.vscale intrinsic calls (#114033)

Teach SCCP to compute a constant range for calls to llvm.vscale
intrinsics.

[SCCP] Simplify code with DenseMap::operator[] (NFC) (#112473)

[IPSCCP] Infer attributes on arguments (#107114)

During inter-procedural SCCP, also infer attributes on arguments, not
just return values. This allows other non-interprocedural passes to make
use

[IPSCCP] Infer attributes on arguments (#107114)

During inter-procedural SCCP, also infer attributes on arguments, not
just return values. This allows other non-interprocedural passes to make
use of the information later.

show more ...

[SCCP] Remove LoadInst if it loaded from Constant GlobalVariable (#107245)

This patch removes the `LoadInst` when it loaded from Constant
GlobalVariable. This allows `canRemoveInstruction` functio

[SCCP] Remove LoadInst if it loaded from Constant GlobalVariable (#107245)

This patch removes the `LoadInst` when it loaded from Constant
GlobalVariable. This allows `canRemoveInstruction` function to be
removed.

show more ...

[SCCP] Explicitly mark gep as overdefined if ct eval fails

Don't just leave the result as unknown. I think this currently
works out thanks to undef resolution, but the correct thing to
do is set it

[SCCP] Explicitly mark gep as overdefined if ct eval fails

Don't just leave the result as unknown. I think this currently
works out thanks to undef resolution, but the correct thing to
do is set it to overdefined explicitly.

show more ...

[SCCP] Infer return attributes in SCCP as well (#106732)

We can infer the range/nonnull attributes in non-interprocedural SCCP as
well. The results may be better after the function has been simplif

[SCCP] Infer return attributes in SCCP as well (#106732)

We can infer the range/nonnull attributes in non-interprocedural SCCP as
well. The results may be better after the function has been simplified.

show more ...

[IPSCCP] Intersect attribute info for interprocedural args (#106397)

IPSCCP can currently return worse results than SCCP for arguments that
are tracked interprocedurally, because information from a

[IPSCCP] Intersect attribute info for interprocedural args (#106397)

IPSCCP can currently return worse results than SCCP for arguments that
are tracked interprocedurally, because information from attributes is
not used for them.

Fix this by intersecting in the attribute information when propagating
lattice values from calls.

show more ...

[SCCP] Add more non-null roots

Also consider allocas non-null (subject to the usual caveats),
and consider nonnull/dereferenceable metadata on calls.

[SCCP] Propagate non-null pointers (#106090)

Add NotConstant(Null) roots for nonnull arguments and then propagate
them through nuw/inbounds GEPs.

Having this functionality in SCCP is useful beca

[SCCP] Propagate non-null pointers (#106090)

Add NotConstant(Null) roots for nonnull arguments and then propagate
them through nuw/inbounds GEPs.

Having this functionality in SCCP is useful because it allows reliably
eliminating null comparisons, independently of how deeply nested they
are in selects/phis. This handles cases that would hit a cutoff in
ValueTracking otherwise.

The implementation is something of a MVP, there are a number of obvious
extensions (e.g. allocas are also non-null).

show more ...

[SCCP] Avoid some uses of SCCPSolver::isOverdefined (NFCI)

This is a confusingly named helper than means "is not unknown,
undef or constant". Prefer the more obvious ValueLattice API
instead. Most o

[SCCP] Avoid some uses of SCCPSolver::isOverdefined (NFCI)

This is a confusingly named helper than means "is not unknown,
undef or constant". Prefer the more obvious ValueLattice API
instead. Most of these checks are for values which are forced to
overdefined by undef resolution, in which case only actual
overdefined values are relevant.

show more ...

[SCCP] fix non-determinism (#105758)

the visit order depended on hashing because we iterated over a
SmallPtrSet

[NFC] [SCCP] remove unused functions (#105603)

[SCCP] Add context to SimplifyQuery (#100831)

[DebugInfo][SCCPSolver] Fix missing debug locations (#98876)

Fixes #98875

[SCCP] Add support for vectors (#98026)

Add preliminary support for vectors of integers by using the
`ValueLatticeElement::asConstantRange()` helper instead of a custom
implementation, and relxing

[SCCP] Add support for vectors (#98026)

Add preliminary support for vectors of integers by using the
`ValueLatticeElement::asConstantRange()` helper instead of a custom
implementation, and relxing various integer type checks.

This enables just the part that works automatically, e.g. icmps with a
constant vector operand aren't supported yet.

The change in ssa.copy handling is because asConstantRange() returns an
unknown LV for empty range, while SCCP's getConstantRange() returned a
full range. I've made the change to preserve the existing behavior.

show more ...

[SCCP] Skip bitcasts entirely

The only bitcasts the existing code might be able to handle are
bitcasts between iN and <1 x iN>. Don't bother.

[SCCP] Don't allow undef ranges when performing operations (#93163)

When performing some range operation (e.g. and) on a constant range that
includes undef, we currently just ignore the undef value

[SCCP] Don't allow undef ranges when performing operations (#93163)

When performing some range operation (e.g. and) on a constant range that
includes undef, we currently just ignore the undef value, which is
obviously incorrect. Instead, we can do one of two things:
* Say that the result range also includes undef.
* Treat undef as a full range.

This patch goes with the second approach -- I'd expect it to be a bit
better overall, e.g. it allows preserving the fact that a zext of a
range with undef isn't a full range.

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

show more ...

[SCCP] Add `nneg` flag to `uitofp` if its operand is non-negative

Similiar to the `InstCombine` changes, just furthering the support of
the `uitofp nneg` support.

Closes #86154

[SCCP] Refine trunc with nsw/nuw flags (#87926)

Following #85592, add support for nsw/nuw flags of trunc in SCCP.

[IPSCCP] Add range attribute handling (#86747)

Support the new range attribute to infer ConstantRanges in IPSCCP.

[SCCP] Extend `visitBinaryOperator` to overflowing binary ops

Leverage more refined ranges results when handling overflowing
binary operators.

[RemoveDIs] Reapply 3fda50d3915, insert instructions using iterators

I'd reverted this in 6c7805d5d1 after a bad stage. Original commit
messsage follows:

[NFC][RemoveDIs] Bulk update utilities to i

[RemoveDIs] Reapply 3fda50d3915, insert instructions using iterators

I'd reverted this in 6c7805d5d1 after a bad stage. Original commit
messsage follows:

[NFC][RemoveDIs] Bulk update utilities to insert with iterators

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can carry a bit of
debug-info. This commit implements some of that by updating the contents of
llvm/lib/Transforms/Utils to always use iterator-versions of instruction
constructors.

There are two general flavours of update:
* Almost all call-sites just call getIterator on an instruction
* Several make use of an existing iterator (scenarios where the code is
actually significant for debug-info)
The underlying logic is that any call to getFirstInsertionPt or similar
APIs that identify the start of a block need to have that iterator passed
directly to the insertion function, without being converted to a bare
Instruction pointer along the way.

I've also switched DemotePHIToStack to take an optional iterator: it needs
to take an iterator, and having a no-insert-location behaviour appears to
be important. The constructors for ICmpInst and FCmpInst have been updated
too. They're the only instructions that take block _references_ rather than
pointers for certain calls, and a future patch is going to make use of
default-null block insertion locations.

All of this should be NFC.

show more ...

Revert "[NFC][RemoveDIs] Bulk update utilities to insert with iterators"

This reverts commit 3fda50d3915b2163a54a37b602be7783a89dd808.

Apparently I've missed a hunk while staging this; will back ou

Revert "[NFC][RemoveDIs] Bulk update utilities to insert with iterators"

This reverts commit 3fda50d3915b2163a54a37b602be7783a89dd808.

Apparently I've missed a hunk while staging this; will back out for now.

Picked up here: https://lab.llvm.org/buildbot/#/builders/139/builds/60429/steps/6/logs/stdio

show more ...

[NFC][RemoveDIs] Bulk update utilities to insert with iterators

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can carr

[NFC][RemoveDIs] Bulk update utilities to insert with iterators

As part of the RemoveDIs project we need LLVM to insert instructions using
iterators wherever possible, so that the iterators can carry a bit of
debug-info. This commit implements some of that by updating the contents of
llvm/lib/Transforms/Utils to always use iterator-versions of instruction
constructors.

There are two general flavours of update:
* Almost all call-sites just call getIterator on an instruction
* Several make use of an existing iterator (scenarios where the code is
actually significant for debug-info)
The underlying logic is that any call to getFirstInsertionPt or similar
APIs that identify the start of a block need to have that iterator passed
directly to the insertion function, without being converted to a bare
Instruction pointer along the way.

I've also switched DemotePHIToStack to take an optional iterator: it needs
to take an iterator, and having a no-insert-location behaviour appears to
be important. The constructors for ICmpInst and FCmpInst have been updated
too. They're the only instructions that take block _references_ rather than
pointers for certain calls, and a future patch is going to make use of
default-null block insertion locations.

All of this should be NFC.

show more ...