[llvm] Construct SmallVector with ArrayRef (NFC) (#102712)

Without this patch, the constructor arguments come from
SmallVectorImpl, not ArrayRef. This patch switches them to ArrayRef
so that we c

[llvm] Construct SmallVector with ArrayRef (NFC) (#102712)

Without this patch, the constructor arguments come from
SmallVectorImpl, not ArrayRef. This patch switches them to ArrayRef
so that we can construct SmallVector with a single argument.

Note that LLVM Programmer’s Manual prefers ArrayRef to SmallVectorImpl
for flexibility.

show more ...

[LCSSA] Cache the loop exit blocks across recursive analysis (NFC) (#101087)

The computation of loop exit blocks recently showed up as a huge compile
time cost for a large file. This computation wa

[LCSSA] Cache the loop exit blocks across recursive analysis (NFC) (#101087)

The computation of loop exit blocks recently showed up as a huge compile
time cost for a large file. This computation was already being cached
during an invocation of formLCSSAForInstructions, but can also be cached
across callers formLCSSA and formLCSSARecursively (the latter was what
was being invoked in the examined case).

Since each of these functions has an external entry point invoked from
other passes, doing so required refactoring each into a worker mechanism
that takes a LoopExitBlocks map, and the externally callable version
that declares the map. That way we can pass it down from the outermost
formLCSSARecursively.

This reduced the time spent in the LCSSA pass from ~110s to ~1s.

show more ...

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which re

[RemoveDIs][NFC] Rename DPValue -> DbgVariableRecord (#85216)

This is the major rename patch that prior patches have built towards.
The DPValue class is being renamed to DbgVariableRecord, which reflects
the updated terminology for the "final" implementation of the RemoveDI
feature. This is a pure string substitution + clang-format patch. The
only manual component of this patch was determining where to perform
these string substitutions: `DPValue` and `DPV` are almost exclusively
used for DbgRecords, *except* for:

- llvm/lib/target, where 'DP' is used to mean double-precision, and so
appears as part of .td files and in variable names. NB: There is a
single existing use of `DPValue` here that refers to debug info, which
I've manually updated.
- llvm/tools/gold, where 'LDPV' is used as a prefix for symbol
visibility enums.

Outside of these places, I've applied several basic string
substitutions, with the intent that they only affect DbgRecord-related
identifiers; I've checked them as I went through to verify this, with
reasonable confidence that there are no unintended changes that slipped
through the cracks. The substitutions applied are all case-sensitive,
and are applied in the order shown:

```
DPValue -> DbgVariableRecord
DPVal -> DbgVarRec
DPV -> DVR
```

Following the previous rename patches, it should be the case that there
are no instances of any of these strings that are meant to refer to the
general case of DbgRecords, or anything other than the DPValue class.
The idea behind this patch is therefore that pure string substitution is
correct in all cases as long as these assumptions hold.

show more ...

[DebugInfo][RemoveDIs] Handle DPValues in LCSSA (#72996)

LCSSA needs to manually update dbg.value intrinsic users of Values that
are having LCSSA PHIs inserted -- instrument it to do the same for

[DebugInfo][RemoveDIs] Handle DPValues in LCSSA (#72996)

LCSSA needs to manually update dbg.value intrinsic users of Values that
are having LCSSA PHIs inserted -- instrument it to do the same for
DPValues, the replacement for dbg.values.

This patch also contains an opportunistic fix replacing
instruction-insertion with iterator-insertion, necessary for
communicating debug-info in the future.

show more ...

[LCSSA] Compute SCEV of LCSSA phi if original instruction had SCEV

The backstory is that the LCSSA invalidation we perform here is not
really necessary from a SCEV perspective. However, other code m

[LCSSA] Compute SCEV of LCSSA phi if original instruction had SCEV

The backstory is that the LCSSA invalidation we perform here is not
really necessary from a SCEV perspective. However, other code may
rely on the fact that invalidating only LCSSA phi nodes is sufficient
for transforms like loop peeling
(see https://reviews.llvm.org/D149331#4398582 for more details).

However, performing invalidation during LCSSA construction also
means that SCEV expansion (which may need to construct LCSSA) can
invalidate SCEV, which is somewhat unexpected and code may not be
prepared to deal with it (see the added test case, reported at
https://reviews.llvm.org/D149435#4428219).

Instead of invalidating SCEV, ensure that the LCSSA phi node also
has cached SCEV if the original instruction did. This means that
later invalidation of LCSSA phi nodes will work as expected. This
should avoid both the above issues and be more efficient.

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

show more ...

Revert "[LCSSA] Don't invalidate SCEV"

This reverts commit 5cbb9f7a58d98ba432c6ddeefa581f6fc521315c.

Causes verifier error reported at
https://reviews.llvm.org/D149331#4387931.

Revert "[LCSSA] Remove unused ScalarEvolution argument (NFC)"

This reverts commit 5362a0d859d8e96b3f7c0437b7866e17a818a4f7.

In preparation for reverting a dependent revision.

[SCEVExpander] Remember phi nodes inserted by LCSSA construction

SCEVExpander keeps track of all instructions it inserted. However,
it currently misses some phi nodes created during LCSSA constructi

[SCEVExpander] Remember phi nodes inserted by LCSSA construction

SCEVExpander keeps track of all instructions it inserted. However,
it currently misses some phi nodes created during LCSSA construction.
Fix this by collecting these into another argument.

This also removes the IRBuilder argument, which was added for
essentially the same purpose, but only handles the root LCSSA nodes,
not those inserted by SSAUpdater.

This was reported as a regression on D149344, but the reduced test
case also reproduces without it.

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

show more ...

[LCSSA] Remove unused ScalarEvolution argument (NFC)

After D149435, LCSSA formation no longer needs access to
ScalarEvolution, so remove the argument from the utilities.

[LCSSA] Don't invalidate SCEV

LCSSA currently invalidates SCEV for all instructions for which
LCSSA phi nodes are created. This used to be necessary, because
SCEV has historically tried to maintain

[LCSSA] Don't invalidate SCEV

LCSSA currently invalidates SCEV for all instructions for which
LCSSA phi nodes are created. This used to be necessary, because
SCEV has historically tried to maintain LCSSA form as well. As
such, some SCEV uses of the value would have to become uses of
the phi node instead.

However, nowadays SCEV itself no longer maintains LCSSA form.
The SCEV of on LCSSA phi node will be the same as the SCEV of its
argument. LCSSA is instead maintained in the SCEVExpander.

As such, I believe it is no longer necessary to perform any SCEV
invalidation during LCSSA construction.

After this patch the ScalarEvolution argument to the LCSSA utilities
is no longer necessary -- I'll remove it in a followup NFC patch to
keep this patch more concise.

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

show more ...

[LCSSA] Don't invalidate entire loop in SCEV

We already invalidate each individual instruction for which LCSSA
is formed in formLCSSAForInstructions(), so I don't see a reason
why we would need to i

[LCSSA] Don't invalidate entire loop in SCEV

We already invalidate each individual instruction for which LCSSA
is formed in formLCSSAForInstructions(), so I don't see a reason
why we would need to invalidate the entire loop on top of that.

I believe we also no longer need the instruction-level invalidation
now that SCEV looks through LCSSA phis, but I'll leave that for a
separate patch, as it's less obvious.

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

show more ...

[LCSSA] Update unreachable uses with poison.

Users of LCSSA may not expect non-phi uses when checking the uses
outside a loop, which may cause crashes. This is due to the fact that we
do not update

[LCSSA] Update unreachable uses with poison.

Users of LCSSA may not expect non-phi uses when checking the uses
outside a loop, which may cause crashes. This is due to the fact that we
do not update uses in unreachable blocks.

To ensure all reachable uses outside the loop are phis, update uses in
unreachable blocks to use poison in dead code.

Fixes #57508.

show more ...

[Transforms] Qualify auto in range-based for loops (NFC)

Identified with readability-qualified-auto.

[LCSSA] Skip updating users in unreachable blocks.

Don't waste time trying to update users in unreachable blocks.

[Transforms] Qualify auto in range-based for loops (NFC)

Identified with readability-qualified-auto.

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

Cleanup includes: TransformsUtils

Estimation on the impact on preprocessor output:
before: 1065307662
after: 1064800684

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

show more ...

[NFC] Remove unnecessary #includes

An attempt to reduce the number of files that are recompiled due to a change.

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

Silence a few unused variable warnings. NFC.

Fix typo s/beloinging/belonging

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

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

[DebugInfo] Move the findDbg* functions into DebugInfo.cpp

Move the findDbg* functions into lib/IR/DebugInfo.cpp from
lib/Transforms/Utils/Local.cpp.

D99169 adds a call to a function (findDbgUsers)

[DebugInfo] Move the findDbg* functions into DebugInfo.cpp

Move the findDbg* functions into lib/IR/DebugInfo.cpp from
lib/Transforms/Utils/Local.cpp.

D99169 adds a call to a function (findDbgUsers) that lives in
lib/Transforms/Utils/Local.cpp (LLVMTransformUtils) from lib/IR/Value.cpp
(LLVMCore). The Core lib doesn't include TransformUtils. The builtbots caught
this here: https://lab.llvm.org/buildbot/#/builders/109/builds/12664. This patch
moves the function, and the 3 similar ones for consistency, into DebugInfo.cpp
which is part of LLVMCore.

Reviewed By: dblaikie, rnk

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

show more ...

[DebugInfo] Support DIArgList in DbgVariableIntrinsic

This patch updates DbgVariableIntrinsics to support use of a DIArgList for the
location operand, resulting in a significant change to its interf

[DebugInfo] Support DIArgList in DbgVariableIntrinsic

This patch updates DbgVariableIntrinsics to support use of a DIArgList for the
location operand, resulting in a significant change to its interface. This patch
does not update all IR passes to support multiple location operands in a
dbg.value; the only change is to update the DbgVariableIntrinsic interface and
its uses. All code outside of the intrinsic classes assumes that an intrinsic
will always have exactly one location operand; they will still support
DIArgLists, but only if they contain exactly one Value.

Among other changes, the setOperand and setArgOperand functions in
DbgVariableIntrinsic have been made private. This is to prevent code from
setting the operands of these intrinsics directly, which could easily result in
incorrect/invalid operands being set. This does not prevent these functions from
being called on a debug intrinsic at all, as they can still be called on any
CallInst pointer; it is assumed that any code directly setting the operands on a
generic call instruction is doing so safely. The intention for making these
functions private is to prevent DIArgLists from being overwritten by code that's
naively trying to replace one of the Values it points to, and also to fail fast
if a DbgVariableIntrinsic is updated to use a DIArgList without a valid
corresponding DIExpression.

show more ...

[llvm] Construct SmallVector with iterator ranges (NFC)

[DebugInfo] Avoid re-ordering assignments in LCSSA

The LCSSA pass makes use of a function insertDebugValuesForPHIs() to
propogate dbg.value() intrinsics to newly inserted PHI instructions. Faulty
be

[DebugInfo] Avoid re-ordering assignments in LCSSA

The LCSSA pass makes use of a function insertDebugValuesForPHIs() to
propogate dbg.value() intrinsics to newly inserted PHI instructions. Faulty
behaviour occurs when the parent PHI of a newly inserted PHI is not the
most recent assignment to a source variable. insertDebugValuesForPHIs ends
up propagating a value that isn't the most recent assignemnt.

This change removes the call to insertDebugValuesForPHIs() from LCSSA,
preventing incorrect dbg.value intrinsics from being propagated.
Propagating variable locations between blocks will occur later, during
LiveDebugValues.

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

show more ...

[LCSSA] Doc for special treatment of PHIs

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