[JumpThreading] Avoid threadThroughTwoBasicBlocks when PredPred BB ends with indirectbranch

Since we can't change the destination of indirectbr, so when
encounter indirectbr as PredPredBB terminator

[JumpThreading] Avoid threadThroughTwoBasicBlocks when PredPred BB ends with indirectbranch

Since we can't change the destination of indirectbr, so when
encounter indirectbr as PredPredBB terminator, we should pass it.

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

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 ...

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

[JumpThreading] Avoid ConstantExpr::get() (NFCI)

This code requires the result to be an UndefValue/ConstantInt
anyway (checked by getKnownConstant), so we are only interested
in the case where this

[JumpThreading] Avoid ConstantExpr::get() (NFCI)

This code requires the result to be an UndefValue/ConstantInt
anyway (checked by getKnownConstant), so we are only interested
in the case where this folds.

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 ...

Use llvm::less_second (NFC)

[JumpThreading][NFCI] Reuse existing DT instead of recomputation

This whole part with recomputation of BPI and BFI looks redundant,
and we tried to get rid of it in D124439. Unfortunately, it causes

[JumpThreading][NFCI] Reuse existing DT instead of recomputation

This whole part with recomputation of BPI and BFI looks redundant,
and we tried to get rid of it in D124439. Unfortunately, it causes
some hard-to-reproduce failures due to invalid state of analysis.
Until this is investigated and fixed, let's try to reuse at least
part of available analyzes.

DT is available at this point, and there is no need to recompute it.

Please revert if you see it causing *any* behavior changes.

show more ...

[NFC][JumpThreading] Remove InsertFreezeWhenUnfoldingSelect pass parameter

All callers pass true.

select-unfold-freeze.ll is now a subset of select.ll so delete it.

Reviewed By: nikic

Differentia

[NFC][JumpThreading] Remove InsertFreezeWhenUnfoldingSelect pass parameter

All callers pass true.

select-unfold-freeze.ll is now a subset of select.ll so delete it.

Reviewed By: nikic

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

show more ...

[JumpThreading] Insert freeze when unfolding select

JumpThreading may convert selects into branch instructions,
in which case the condition needs to be frozen (as branch on
poison is immediate undef

[JumpThreading] Insert freeze when unfolding select

JumpThreading may convert selects into branch instructions,
in which case the condition needs to be frozen (as branch on
poison is immediate undefined behavior, unlike select on poison).

The necessary code for this is already in place, this just enables
the option.

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

show more ...

[JumpThreading] Look through freeze in getPredicateAt() fold

This code is valid for any icmp, so we can safely look through a
freeze when trying to find one.

A caveat here is that replaceFoldableUs

[JumpThreading] Look through freeze in getPredicateAt() fold

This code is valid for any icmp, so we can safely look through a
freeze when trying to find one.

A caveat here is that replaceFoldableUses() may not end up replacing
any uses in this case. It might make sense to use the freeze as the
context instruction (rather than the terminator) if there is a
freeze, to ensure that it always gets folded. This would require
some changes to how replaceFoldedUses() works though, as it
currently assumes that the value is valid at the end of the block.

show more ...

[JumpThreading] Simplify getPredicateAt() based folding

It's sufficient to just fold the icmp to true/false here, and then
let constant terminator folding take care of the rest.

It should be noted

[JumpThreading] Simplify getPredicateAt() based folding

It's sufficient to just fold the icmp to true/false here, and then
let constant terminator folding take care of the rest.

It should be noted that while replaceFoldableUses() may not replace
all uses of the icmp, at least the use in the terminator we're
working on is always replaceable, so terminator constant folding
should be reliably enabled as a subsequent step.

show more ...

[JumpThreading] Use common code to skip freeze (NFC)

There are multiple places that want to look through freeze, so
store condition without freeze in a separate variable.

[JumpThreading] Let ProcessImpliedCondition look into freeze instructions

This patch makes JumpThreading's ProcessImpliedCondition deal with frozen
conditions.

Reviewed By: nikic

Differential Revi

[JumpThreading] Let ProcessImpliedCondition look into freeze instructions

This patch makes JumpThreading's ProcessImpliedCondition deal with frozen
conditions.

Reviewed By: nikic

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

show more ...

[JumpThreading] Don't pass DT to isGuaranteedNotToBeUndefOrPoison()

JumpThreading intentionally does not force updating of the DT
during optimization, because this may be expensive when many CFG
upd

[JumpThreading] Don't pass DT to isGuaranteedNotToBeUndefOrPoison()

JumpThreading intentionally does not force updating of the DT
during optimization, because this may be expensive when many CFG
updates and DT calculations are interleaved.

We shouldn't be fetching the DT just for the purpose of calling
isGuaranteedNotToBeUndefOrPoison(), especially as DT availability
doesn't even show benefit in tests.

show more ...

Revert "[JumpThreading][NFC][CompileTime] Do not recompute BPI/BFI analyzes"

This change has caused non-reproducibility of a self-build of Clang
when using NewPM and providing profile data.

This re

Revert "[JumpThreading][NFC][CompileTime] Do not recompute BPI/BFI analyzes"

This change has caused non-reproducibility of a self-build of Clang
when using NewPM and providing profile data.

This reverts commit 35f38583d2f2484794f579bed69566b40e732206.

show more ...

[JumpThreading][NFC][CompileTime] Do not recompute BPI/BFI analyzes

They can already be available, and even if not, DT/LI can be available.
We should not recompute them. Old PM is unchanged because

[JumpThreading][NFC][CompileTime] Do not recompute BPI/BFI analyzes

They can already be available, and even if not, DT/LI can be available.
We should not recompute them. Old PM is unchanged because it would
require changing dependencies, and we don't care enough about it.

Differential Revision: https://reviews.llvm.org/D124439
Reviewed By: nikic, aeubanks

show more ...

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cl

Cleanup includes: Transform/Scalar

Estimated impact on preprocessor output line:
before: 1062981579
after: 1062494547

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D120817

show more ...

[JumpThreading] Change asserts for WantInteger into actual checks

After e734e8286b4b521d829aaddb6d1cbbd264953625, it is possible to end up in
a situation where an `indirectbr` is fed by a cast, whic

[JumpThreading] Change asserts for WantInteger into actual checks

After e734e8286b4b521d829aaddb6d1cbbd264953625, it is possible to end up in
a situation where an `indirectbr` is fed by a cast, which is in turn fed by
an operation which only produces integers.

`indirectbr` expects a block address, however these operations can't produce
that.

There were several asserts in `computeValueKnownInPredecessorsImpl` which check
that we're not looking for a block address if we're walking through something
which can never produce one.

Since it's now possible to hit these asserts, this changes them into actual
checks which return false if `Preference` is not `WantInteger`.

This adds a testcase which verifies that we don't crash anymore in these
situations.

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

show more ...

Re-apply "[JumpThreading] Ignore free instructions"

It seems the crashes we saw wasn't caused by this (see comments on the review).

> This is basically D108837 but for jump threading. Free instruct

Re-apply "[JumpThreading] Ignore free instructions"

It seems the crashes we saw wasn't caused by this (see comments on the review).

> This is basically D108837 but for jump threading. Free instructions
> should be ignored for the threading decision. JumpThreading already
> skips some free instructions (like pointer bitcasts), but does not
> skip various free intrinsics -- in fact, it currently gives them a
> fairly large cost of 2.
>
> Differential Revision: https://reviews.llvm.org/D110290

This reverts commit 4604695d7c20e72b551a1a5224f3de877cb41bd3.

show more ...

Revert "[JumpThreading] Ignore free instructions"

It caused compiler crashes, see comment on the code review for repro.

> This is basically D108837 but for jump threading. Free instructions
> shoul

Revert "[JumpThreading] Ignore free instructions"

It caused compiler crashes, see comment on the code review for repro.

> This is basically D108837 but for jump threading. Free instructions
> should be ignored for the threading decision. JumpThreading already
> skips some free instructions (like pointer bitcasts), but does not
> skip various free intrinsics -- in fact, it currently gives them a
> fairly large cost of 2.
>
> Differential Revision: https://reviews.llvm.org/D110290

This reverts commit 1e3c6fc7cb9d2ee6a5328881f95d6643afeadbff.

show more ...

[JumpThreading] Ignore free instructions

This is basically D108837 but for jump threading. Free instructions
should be ignored for the threading decision. JumpThreading already
skips some free instr

[JumpThreading] Ignore free instructions

This is basically D108837 but for jump threading. Free instructions
should be ignored for the threading decision. JumpThreading already
skips some free instructions (like pointer bitcasts), but does not
skip various free intrinsics -- in fact, it currently gives them a
fairly large cost of 2.

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

show more ...

[IR] Return AAMDNodes from Instruction::getMetadata() (NFC)

getMetadata() currently uses a weird API where it populates a
structure passed to it, and optionally merges into it. Instead,
we can retur

[IR] Return AAMDNodes from Instruction::getMetadata() (NFC)

getMetadata() currently uses a weird API where it populates a
structure passed to it, and optionally merges into it. Instead,
we can return the AAMDNodes and provide a separate merge() API.
This makes usages more compact.

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

show more ...

[CSSPGO] Undoing the concept of dangling pseudo probe

As a follow-up to https://reviews.llvm.org/D104129, I'm cleaning up the danling probe related code in both the compiler and llvm-profgen.

I'm s

[CSSPGO] Undoing the concept of dangling pseudo probe

As a follow-up to https://reviews.llvm.org/D104129, I'm cleaning up the danling probe related code in both the compiler and llvm-profgen.

I'm seeing a 5% size win for the pseudo_probe section for SPEC2017 and 10% for Ciner. Certain benchmark such as 602.gcc has a 20% size win. No obvious difference seen on build time for SPEC2017 and Cinder.

Reviewed By: wenlei

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

show more ...

[NewPM] Don't mark AA analyses as preserved

Currently all AA analyses marked as preserved are stateless, not taking
into account their dependent analyses. So there's no need to mark them
as preserve

[NewPM] Don't mark AA analyses as preserved

Currently all AA analyses marked as preserved are stateless, not taking
into account their dependent analyses. So there's no need to mark them
as preserved, they won't be invalidated unless their analyses are.

SCEVAAResults was the one exception to this, it was treated like a
typical analysis result. Make it like the others and don't invalidate
unless SCEV is invalidated.

Reviewed By: asbirlea

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

show more ...

[JumpThreading] merge debug info when merging select+br

Jump threading can replace select then unconditional branch with
conditional branch, but when doing so loses debug info.

This destructive tra

[JumpThreading] merge debug info when merging select+br

Jump threading can replace select then unconditional branch with
conditional branch, but when doing so loses debug info.

This destructive transform is eventually leading to a failed Verifier
run during full LTO builds of the Linux kernel with CFI and KCOV
enabled, as reported in PR39531.

ModuleSanitizerCoveragePass will insert calls to
__sanitizer_cov_trace_pc, and sometimes split critical edges,
using whatever debug info may or may not exist for the branch for
the added libcall. Since we can inline calls to
__sanitizer_cov_trace_pc due to LTO, this can lead to the error
observed in PR39531 when the debug info isn't propagated to
the libcall, because of prior destructive transforms that failed to
retain debug info.

Reviewed By: dblaikie

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

show more ...