Reapply "[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265) (#91372)

This reverts commit 924384161ffceda08099536dd07a953299a69b53.

This reland

Reapply "[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265) (#91372)

This reverts commit 924384161ffceda08099536dd07a953299a69b53.

This reland addresses the performance regressions seen in #90265 by
retaining the original definition of
`isPotentiallyReachableFromMany(...)` instead of reimplementing it with
`isManyPotentiallyReachableFromMany(...)`.

Fixes #86580

show more ...

Revert "[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265)"

This reverts commit fcf341d3ddfe2289ac88aa3c122b25df8732cc8e.

Causes major compile-t

Revert "[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265)"

This reverts commit fcf341d3ddfe2289ac88aa3c122b25df8732cc8e.

Causes major compile-time regressions when not using coroutines.

show more ...

[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265)

The current logic for using lifetime intrinsics to determine whether a
coroutine alloca shoul

[coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (#90265)

The current logic for using lifetime intrinsics to determine whether a
coroutine alloca should live on the coroutine frame or stack doesn't
consider `llvm.lifetime.end`. As a result, some allocas are incorrectly
placed on the stack even though their lifetimes may outlive the stack.
For example, SimplifyCFG may generate code that drops the corresponding
`llvm.lifetime.end` of an `llvm.lifetime.start`, and that code is
incorrectly handled by the existing logic.

To fix this, new logic is introduced where if an alloca's address is
escaped, and there is a path from an `llvm.lifetime.start` to a
coroutine suspend point (e.g. `llvm.coro.suspend`) without an
`llvm.lifetime.end`, then we know the object lives beyond the suspension
point and therefore must go on the coroutine frame.

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

show more ...

[CFG] Add const qualifier to isPotentiallyReachableFromMany() (NFC)

Accept a const pointer for StopBB. Unfortunately the worklist has
to use non-const pointers due to LoopInfo interaction.

[Analysis] Qualify auto variables in for loops (NFC)

[LoopInfo] Add getOutermostLoop() (NFC)

This is a recurring pattern, add an API function for it.

[CFG] Move reachable from entry checks into basic block variant

These checks are not specific to the instruction based variant of
isPotentiallyReachable(), they are equally valid for the basic
block

[CFG] Move reachable from entry checks into basic block variant

These checks are not specific to the instruction based variant of
isPotentiallyReachable(), they are equally valid for the basic
block based variant. Move them there, to make sure that switching
between the instruction and basic block variants cannot introduce
regressions.

show more ...

[IR] Add BasicBlock::isEntryBlock() (NFC)

This is a recurring and somewhat awkward pattern. Add a helper
method for it.

[CFG] Use comesBefore() (NFC)

Use comesBefore() instead of performing an instruction walk. In
line with the previous implementation, instructions are considered
to reach themselves.

[Analysis] Use is_contained (NFC)

[CFG] Replace hardcoded max BBs explored as CL option. NFC.

This option was hardcoded to 32. Changing this as a CL option since we
have seen some cases downstream where increasing this limit allows

[CFG] Replace hardcoded max BBs explored as CL option. NFC.

This option was hardcoded to 32. Changing this as a CL option since we
have seen some cases downstream where increasing this limit allows us to
disprove reachability.

Reviewed-By: jdoerfert
Differential Revision: https://reviews.llvm.org/D90487

show more ...

CFG.h - reduce includes to forward declarations. NFC.

Remove unnecessary includes from CFG.cpp.

Fix implicit include dependency in X86WinEHState.cpp.

[CFG/BasicBlock] Rename succ_const to const_succ. [NFC]

Summary:
Rename `succ_const_iterator` to `const_succ_iterator` and
`succ_const_range` to `const_succ_range` for consistency with the
predecess

[CFG/BasicBlock] Rename succ_const to const_succ. [NFC]

Summary:
Rename `succ_const_iterator` to `const_succ_iterator` and
`succ_const_range` to `const_succ_range` for consistency with the
predecessor iterators, and the corresponding iterators in
MachineBasicBlock.

Reviewers: nicholas, dblaikie, nlewycky

Subscribers: hiraditya, bmahjour, llvm-commits

Tags: #llvm

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

show more ...

Recommit "[GVN] Preserve loop related analysis/canonical forms."

This fixes some pipeline tests.
This reverts commit d0b6f42936bfb6d56d325c732ae79400c9c6016a.

llvm-svn: 367401

Revert [GVN] Preserve loop related analysis/canonical forms.

This reverts r367332 (git commit 2d7227ec3ac91f36fc32b1c21e72e2f1f5d030ad)

llvm-svn: 367335

[GVN] Preserve loop related analysis/canonical forms.

LoopInfo can be easily preserved by passing it to the functions that
modify the CFG (SplitCriticalEdge and MergeBlockIntoPredecessor.
SplitCriti

[GVN] Preserve loop related analysis/canonical forms.

LoopInfo can be easily preserved by passing it to the functions that
modify the CFG (SplitCriticalEdge and MergeBlockIntoPredecessor.
SplitCriticalEdge also preserves LoopSimplify and LCSSA form when when passing in
LoopInfo. The test case shows that we preserve LoopSimplify and
LoopInfo. Adding addPreservedID(LCSSAID) did not preserve LCSSA for some
reason.

Also I am not sure if it is possible to preserve those in the new pass
manager, as they aren't analysis passes.

Reviewers: reames, hfinkel, davide, jdoerfert

Reviewed By: jdoerfert

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

llvm-svn: 367332

show more ...

An unreachable block may have a route to a reachable block, don't fast-path return that it can't.

A block reachable from the entry block can't have any route to a block that's not reachable from the

An unreachable block may have a route to a reachable block, don't fast-path return that it can't.

A block reachable from the entry block can't have any route to a block that's not reachable from the entry block (if it did, that route would make it reachable from the entry block). That is the intended performance optimization for isPotentiallyReachable. For the case where we ask whether an unreachable from entry block has a route to a reachable from entry block, we can't conclude one way or the other. Fix a bug where we claimed there could be no such route.

The fix in rL357425 ironically reintroduced the very bug it was fixing but only when a DominatorTree is provided. This fixes the remaining bug.

llvm-svn: 357734

show more ...

Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable.

The leads to some ambiguous overloads, so update three callers.

Differential Revision: https://reviews.llv

Add an optional list of blocks to avoid when looking for a path in isPotentiallyReachable.

The leads to some ambiguous overloads, so update three callers.

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

llvm-svn: 357447

show more ...

Not all blocks are reachable from entry. Don't assume they are.

Fixes a bug in isPotentiallyReachable, noticed by inspection.

llvm-svn: 357425

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[TI removal] Make variables declared as `TerminatorInst` and initialized
by `getTerminator()` calls instead be declared as `Instruction`.

This is the biggest remaining chunk of the usage of `getTerm

[TI removal] Make variables declared as `TerminatorInst` and initialized
by `getTerminator()` calls instead be declared as `Instruction`.

This is the biggest remaining chunk of the usage of `getTerminator()`
that insists on the narrow type and so is an easy batch of updates.
Several files saw more extensive updates where this would cascade to
requiring API updates within the file to use `Instruction` instead of
`TerminatorInst`. All of these were trivial in nature (pervasively using
`Instruction` instead just worked).

llvm-svn: 344502

show more ...

[TI removal] Remove TerminatorInst as an input parameter from all public
LLVM APIs. There weren't very many.

We still have the instruction visitor, and APIs with TerminatorInst as
a return type or a

[TI removal] Remove TerminatorInst as an input parameter from all public
LLVM APIs. There weren't very many.

We still have the instruction visitor, and APIs with TerminatorInst as
a return type or an output parameter.

llvm-svn: 344494

show more ...

Avoid overly large SmallPtrSet/SmallSet

These sets perform linear searching in small mode so it is never a good
idea to use SmallSize/N bigger than 32.

llvm-svn: 259283

Add some constantness to GetSuccessorNumber().

llvm-svn: 253733

Analysis: Remove implicit ilist iterator conversions

Remove implicit ilist iterator conversions from LLVMAnalysis.

I came across something really scary in `llvm::isKnownNotFullPoison()`
which relie

Analysis: Remove implicit ilist iterator conversions

Remove implicit ilist iterator conversions from LLVMAnalysis.

I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.

Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.

I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:

Instruction *PrevInsertPoint = Builder.GetInsertPoint();

/* Logic that may change insert point */

if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);

The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.

llvm-svn: 249925

show more ...