[NFC] Switch a few uses of undef to poison as placeholders for unreachable code

[SimplifyCFG] Improve SwitchToLookupTable optimization

Try to use the original value as an index (in the lookup table)
in more cases (to avoid one subtraction and shorten the dependency chain)
(http

[SimplifyCFG] Improve SwitchToLookupTable optimization

Try to use the original value as an index (in the lookup table)
in more cases (to avoid one subtraction and shorten the dependency chain)
(https://github.com/llvm/llvm-project/issues/56189).

Test plan:
1/ ninja check-all
2/ bootstrapped LLVM + Clang pass tests

Differential revision: https://reviews.llvm.org/D128897

show more ...

[coroutine] add nomerge function attribute to `llvm.coro.save`

It is illegal to merge two `llvm.coro.save` calls unless their
`llvm.coro.suspend` users are also merged. Marks it "nomerge" for
the mo

[coroutine] add nomerge function attribute to `llvm.coro.save`

It is illegal to merge two `llvm.coro.save` calls unless their
`llvm.coro.suspend` users are also merged. Marks it "nomerge" for
the moment.

This reverts D129025.

Alternative to D129025, which affects other token type users like WinEH.

Reviewed By: ChuanqiXu

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

show more ...

[BasicBlockUtils] Allow splitting predecessors with callbr terminators

SplitBlockPredecessors currently asserts if one of the predecessor
terminators is a callbr. This limitation was originally nece

[BasicBlockUtils] Allow splitting predecessors with callbr terminators

SplitBlockPredecessors currently asserts if one of the predecessor
terminators is a callbr. This limitation was originally necessary,
because just like with indirectbr, it was not possible to replace
successors of a callbr. However, this is no longer the case since
D67252. As the requirement nowadays is that callbr must reference
all blockaddrs directly in the call arguments, and these get
automatically updated when setSuccessor() is called, we no longer
need this limitation.

The only thing we need to do here is use replaceSuccessorWith()
instead of replaceUsesOfWith(), because only the former does the
necessary blockaddr updating magic.

I believe there's other similar limitations that can be removed,
e.g. related to critical edge splitting.

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

show more ...

[SimplifyCFG] Don't split predecessors of callbr terminator

This addresses the assertion failure reported in
https://reviews.llvm.org/D124159#3631240.

I believe that this limitation in SplitBlockPr

[SimplifyCFG] Don't split predecessors of callbr terminator

This addresses the assertion failure reported in
https://reviews.llvm.org/D124159#3631240.

I believe that this limitation in SplitBlockPredecessors is not
actually necessary (because unlike with indirectbr, callbr is
restricted in a way that does allow updating successors), but for
now fix the assertion failure the same way we do everywhere else,
by also skipping callbr.

show more ...

[ValueTracking] Accept Instruction in isSafeToSpeculativelyExecute() (NFC)

As constant expressions can no longer trap, it only makes sense to
call isSafeToSpeculativelyExecute on Instructions, so li

[ValueTracking] Accept Instruction in isSafeToSpeculativelyExecute() (NFC)

As constant expressions can no longer trap, it only makes sense to
call isSafeToSpeculativelyExecute on Instructions, so limit the
API to accept only them, rather than general Operators or Values.

show more ...

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() m

[IR] Remove Constant::canTrap() (NFC)

As integer div/rem constant expressions are no longer supported,
constants can no longer trap and are always safe to speculate.
Remove the Constant::canTrap() method and its usages.

show more ...

[SimplifyCFG] Skip hoisting common instructions that return token type

By LangRef, hoisting token-returning instructions obsures the origin
so it should be skipped. Found this issue while investigat

[SimplifyCFG] Skip hoisting common instructions that return token type

By LangRef, hoisting token-returning instructions obsures the origin
so it should be skipped. Found this issue while investigating a
CoroSplit pass crash.

Reviewed By: nikic

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

show more ...

Revert "[SimplifyCFG] Thread branches on same condition in more cases (PR54980)"

This reverts commit 4e545bdb355a470d601e9bb7f7b2693c99e61a3e.

The newly added test is the third infinite combine loo

Revert "[SimplifyCFG] Thread branches on same condition in more cases (PR54980)"

This reverts commit 4e545bdb355a470d601e9bb7f7b2693c99e61a3e.

The newly added test is the third infinite combine loop caused by
this change. In this case, it's a combination of the branch to
common dest and jump threading folds that keeps peeling off loop
iterations.

The core problem here is that we ideally would not thread over
loop backedges, both because it is potentially non-profitable
(it may break canonical loop structure) and because it may result
in these kinds of loops. Unfortunately, due to the lack of a
dominator tree in SimplifyCFG, there is no good way to prevent
this. While we have LoopHeaders, this is an optional structure and
we don't do a good job of keeping it up to date. It would be fine
for a profitability check, but is not suitable for a correctness
check.

So for now I'm just giving up here, as I don't see a good way to
robustly prevent infinite combine loops.

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

show more ...

[SimplifyCFG] Thread all predecessors with same value at once

If there are multiple predecessors that have the same condition
value (and thus same "real destination"), these were previously
handled

[SimplifyCFG] Thread all predecessors with same value at once

If there are multiple predecessors that have the same condition
value (and thus same "real destination"), these were previously
handled by copying the threaded block for each predecessor.
Instead, we can reuse one block for all of them. This makes the
behavior of SimplifyCFG's jump threading match that of the
actual JumpThreading pass.

This also avoids the infinite combine loop reported in:
https://reviews.llvm.org/D124159#3624387

show more ...

[SimplifyCFG] Remove redundant checks for hoisting (NFCI)

These conditions are later checked in the HoistTerminator code
path. Checking them here is somewhat confusing, because this code
only checks

[SimplifyCFG] Remove redundant checks for hoisting (NFCI)

These conditions are later checked in the HoistTerminator code
path. Checking them here is somewhat confusing, because this code
only checks the first instruction in the block, which is not
necessarily the terminator.

show more ...

[ConstantFold] Supports compares in ConstantFoldInstOperands()

Support compares in ConstantFoldInstOperands(), instead of
forcing the use of ConstantFoldCompareInstOperands(). Also handle
insertvalu

[ConstantFold] Supports compares in ConstantFoldInstOperands()

Support compares in ConstantFoldInstOperands(), instead of
forcing the use of ConstantFoldCompareInstOperands(). Also handle
insertvalue (extractvalue was already handled).

This removes a footgun, where many uses of ConstantFoldInstOperands()
need a separate check for compares beforehand. It's particularly
insidious if called on a constant expression, because it doesn't
fail in that case, but will just not do DL-dependent folding.

show more ...

[SimplifyCFG] Try to merge edge block when threading (PR55765)

When threading, we always create a new block for the threaded edge
(even if the edge is not critical), which will later get folded back

[SimplifyCFG] Try to merge edge block when threading (PR55765)

When threading, we always create a new block for the threaded edge
(even if the edge is not critical), which will later get folded back
into the predecessor if possible. Depending on precise processing
order, this separate block may break the detection of trivial
cycles in the threading code, which normally avoids infinite
threading of loops. Explicitly merge the created edge block into
the predecessor to avoid this.

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

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

show more ...

Prevent crash when TurnSwitchRangeIntoICmp receives default unreachable destination

TurnSwitchRangeIntoICmp crashes when given a switch with a default
destination of unreachable
Addresses issue #532

Prevent crash when TurnSwitchRangeIntoICmp receives default unreachable destination

TurnSwitchRangeIntoICmp crashes when given a switch with a default
destination of unreachable
Addresses issue #53208
https://github.com/llvm/llvm-project/issues/53208

Differential revision: https://reviews.llvm.org/D127712

show more ...

[SimplifyCFG] Handle trapping aggregates (PR49839)

Handle the fact that not only constant expressions, but also
constant aggregates containing expressions can trap.

This still doesn't fix the origi

[SimplifyCFG] Handle trapping aggregates (PR49839)

Handle the fact that not only constant expressions, but also
constant aggregates containing expressions can trap.

This still doesn't fix the original C reproducer, probably due to
more issues remaining in other passes.

show more ...

[SimplifyCFG] Share code to compute switch density between ShouldBuildLookupTable() and ReduceSwitchRange()

They're computing the same thing. No functionality change.

Differential revision: https:/

[SimplifyCFG] Share code to compute switch density between ShouldBuildLookupTable() and ReduceSwitchRange()

They're computing the same thing. No functionality change.

Differential revision: https://reviews.llvm.org/D127482

show more ...

[NFC] format InstructionSimplify & lowerCaseFunctionNames

Clang-format InstructionSimplify and convert all "FunctionName"s to
"functionName". This patch does touch a lot of files but gets done with

[NFC] format InstructionSimplify & lowerCaseFunctionNames

Clang-format InstructionSimplify and convert all "FunctionName"s to
"functionName". This patch does touch a lot of files but gets done with
the cleanup of InstructionSimplify in one commit.

This is the alternative to the less invasive clang-format only patch: D126783

Reviewed By: spatel, rengolin

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

show more ...

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the err

[llvm] Remove unneeded cl::ZeroOrMore for cl::opt options. NFC

Some cl::ZeroOrMore were added to avoid the `may only occur zero or one times!`
error. More were added due to cargo cult. Since the error has been removed,
cl::ZeroOrMore is unneeded.

Also remove cl::init(false) while touching the lines.

show more ...

[SimplifyCFG] Avoid shifting by a too large exponent.

TI->getBitWidth can be > 64 and in those cases the shift will be UB due
to the exponent being too large.

To fix this, cap the shift at 63. I th

[SimplifyCFG] Avoid shifting by a too large exponent.

TI->getBitWidth can be > 64 and in those cases the shift will be UB due
to the exponent being too large.

To fix this, cap the shift at 63. I think this should work out fine,
because TableSize is itself a 64 bit type and the maximum table size
must fit in the type. Also, if we would underestimate the size here, at
most we get an extra ZExt.

Reviewed By: spatel

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

show more ...

[SimplifyCFG] Replace condition value when threading

Replace the condition value with the known constant value on the
threaded edge. This happens implicitly with phi threading because
we replace wit

[SimplifyCFG] Replace condition value when threading

Replace the condition value with the known constant value on the
threaded edge. This happens implicitly with phi threading because
we replace with the incoming value, but not for non-phi threading.

show more ...

[SimplifyCFG] Thread branches on same condition in more cases (PR54980)

SimplifyCFG implements basic jump threading, if a branch is
performed on a phi node with constant operands. However,
InstCombi

[SimplifyCFG] Thread branches on same condition in more cases (PR54980)

SimplifyCFG implements basic jump threading, if a branch is
performed on a phi node with constant operands. However,
InstCombine canonicalizes such phis to the condition value of a
previous branch, if possible. SimplifyCFG does support this as
well, but only in the very limited case where the same condition
is used in a direct predecessor -- notably, this does not include
the common diamond pattern (i.e. two consecutive if/elses on the
same condition).

This patch extends the code to look back a limited number of
blocks to find a branch on the same value, rather than only
looking at the direct predecessor.

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

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

show more ...

[NFC] Rename Instrinsic to Intrinsic

Reapply [SimplifyCFG] Handle branch on same condition in pred more directly

Reapplying without changes, after a fix to a dependent patch.

-----

Rather than creating a PHI node and then using the P

Reapply [SimplifyCFG] Handle branch on same condition in pred more directly

Reapplying without changes, after a fix to a dependent patch.

-----

Rather than creating a PHI node and then using the PHI threading
code, directly handle this case in
FoldCondBranchOnValueKnownInPredecessor().

This change is supposed to be NFC-ish, but may cause changes due
to different transform order.

show more ...

Reapply [SimplifyCFG] Make FoldCondBranchOnPHI more amenable to extension (NFCI)

Reapply with SmallMapVector instead of SmallDenseMap, which should
address the non-determinism issue.

-----

This ge

Reapply [SimplifyCFG] Make FoldCondBranchOnPHI more amenable to extension (NFCI)

Reapply with SmallMapVector instead of SmallDenseMap, which should
address the non-determinism issue.

-----

This general threading transform can be performed whenever we know
a constant value for the condition in a predecessor, which would
currently just be the case of a phi node with constant arguments.

show more ...

Revert "[SimplifyCFG] Handle branch on same condition in pred more directly" and "[SimplifyCFG] Make FoldCondBranchOnPHI more amenable to extension"

This reverts commit 3df86e799e46bc1139372a2f40c31

Revert "[SimplifyCFG] Handle branch on same condition in pred more directly" and "[SimplifyCFG] Make FoldCondBranchOnPHI more amenable to extension"

This reverts commit 3df86e799e46bc1139372a2f40c31333716e3ad6.
This reverts commit 8988254667fff67d1f585396aa0e9933f5ba69ad.

`[SimplifyCFG] Handle branch on same condition in pred more directly`
caused non-determinism when compiling opt with a bootstrapped clang.
I have to revert the dependent commit as well.

show more ...