[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and sim

[NFC][DebugInfo] Use iterator moveBefore at many call-sites (#123583)

As part of the "RemoveDIs" project, BasicBlock::iterator now carries a
debug-info bit that's needed when getFirstNonPHI and similar feed into
instruction insertion positions. Call-sites where that's necessary were
updated a year ago; but to ensure some type safety however, we'd like to
have all calls to moveBefore use iterators.

This patch adds a (guaranteed dereferenceable) iterator-taking
moveBefore, and changes a bunch of call-sites where it's obviously safe
to change to use it by just calling getIterator() on an instruction
pointer. A follow-up patch will contain less-obviously-safe changes.

We'll eventually deprecate and remove the instruction-pointer
insertBefore, but not before adding concise documentation of what
considerations are needed (very few).

show more ...

[Instrumentation] Support `MachineFunction` in `OptNoneInstrumentation` (#115471)

Support `MachineFunction` in `OptNoneInstrumentation`, also add
`isRequired` to all necessary passes.

[NewPM][CodeGen] Port StackColoring to NPM (#111812)

[CodeGen][NewPM] Port `SlotIndexes` to new pass manager (#97941)

- Add `SlotIndexesAnalysis`.
- Add `SlotIndexesPrinterPass`.
- Use `SlotIndexesWrapperPass` in legacy pass.

[StackColoring] Use poison instead of undef as placeholder when deleting values [NFC]

[StackColoring] Declare BitVector outside the loop (#95688)

The StackColoring pass creates two instances of BitVector per basic
block until the fixed point is reached. Each instance may involve a

[StackColoring] Declare BitVector outside the loop (#95688)

The StackColoring pass creates two instances of BitVector per basic
block until the fixed point is reached. Each instance may involve a
heap allocation depending on its size.

This patch declares them outside the loop, saving 1.40% of heap
allocations during the compilation of CGBuiltin.cpp.ii, a preprocessed
version of CGBuiltin.cpp.

show more ...

Revert "[StackColoring] Delete dead stack slots (#75351)" (#75655)

This reverts commit 08b306dc8e7c0b2498f4f194a3c51686d56dbd20.

it causes the following assertion failure:
llvm/include/llvm/Code

Revert "[StackColoring] Delete dead stack slots (#75351)" (#75655)

This reverts commit 08b306dc8e7c0b2498f4f194a3c51686d56dbd20.

it causes the following assertion failure:
llvm/include/llvm/CodeGen/MachineFrameInfo.h:530: int64_t
llvm::MachineFrameInfo::getObjectOffset(int) const: Assertion
`!isDeadObjectIndex(ObjectIdx) && "Getting frame offset for a dead
object?"' failed.

show more ...

[StackColoring] Delete dead stack slots (#75351)

deletes slots that have lifetime markers and the lifetime ranges are empty.

Revert "[StackColoring] Delete dead stack slots (#72633)"

This reverts commit a29457844bf0c4b2eb5c0f3877b6e8ef30cdef52.

Causes an assertion failure in llvm/test/DebugInfo/COFF/lexicalblock.ll.

[StackColoring] Delete dead stack slots (#72633)

Deletes slots that have lifetime markers and the lifetime ranges are
empty.

[CodeGen] Split off PseudoSourceValueManager into separate header (NFC) (#73327)

Most users of PseudoSourceValue.h only need PseudoSourceValue, not the
PseudoSourceValueManager. However, this heade

[CodeGen] Split off PseudoSourceValueManager into separate header (NFC) (#73327)

Most users of PseudoSourceValue.h only need PseudoSourceValue, not the
PseudoSourceValueManager. However, this header pulls in some very
expensive dependencies like ValueMap.h, which is only used for the
manager.

Split off the manager into a separate header and include it only where
used.

show more ...

[StackColoring] Do not drop AA metadata when not doing remappings (#71958)

In the StackColoring pass we first scan for possible stack slot merges.
A SlotRemap map is setup with the remappings that

[StackColoring] Do not drop AA metadata when not doing remappings (#71958)

In the StackColoring pass we first scan for possible stack slot merges.
A SlotRemap map is setup with the remappings that should be performed.
Then the main work is done by calling remapInstructions and providing
that map.

Most of the work in remapInstructions would just be a waste of time in
situations when the SlotRemap map is empty, but it turns out that the
part that adjusts Alias Analysis information could end up dropping AA
metadata even when there are no stack slot merges being done. This
happens since all instruction's machine memory operands are considered,
and if we can't determine the underlying object that is accessed (using
getUnderlyingObjectsForCodeGen) then we conservatively drop AA metadata.

This patch simply avoids calling remapInstructions if we don't intend to
do any remappings (i.e. if SlotRemap is empty). That avoids touching AA
metadata when all we do is to remove lifetime markers. That seems like a
safe thing to do, as it is the same thing as happens when we bail out
early due to other reasons (e.g. when only having one lifetime marker).

For targets that do not care about Alias Analysis information after the
StackColoring pass this shouldn't have any impact, except that it might
improve compile time slightly as we now skip spending time in
remapInstructions when not doing any stack merges.

show more ...

[StackColoring] Handle fixed object index

This is a followup to #66988. The implementation there did not
account for the possibility of the catch object frame index
referrring to a fixed object, whi

[StackColoring] Handle fixed object index

This is a followup to #66988. The implementation there did not
account for the possibility of the catch object frame index
referrring to a fixed object, which is the case on win64.

show more ...

[StackColoring] Handle SEH catch object stack slots conservatively

The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
b

[StackColoring] Handle SEH catch object stack slots conservatively

The write to the SEH catch object happens before cleanuppads are
executed, while the first reference to the object will typically
be in a catchpad.

If we make use of first-use analysis, we may end up allocating
an alloca used inside the cleanuppad and the catch object at the
same stack offset, which would be incorrect.

https://reviews.llvm.org/D86673 was a previous attempt to fix it.
It used the heuristic "a slot loaded in a WinEH pad and never
written" to detect catch objects. However, because it checks
for more than one load (while probably more than zero was
intended), the fix does not actually work.

The general approach also seems dubious to me, so this patch
reverts that change entirely, and instead marks all catch object
slots as conservative (i.e. excluded from first-use analysis)
based on the WinEHFuncInfo. As far as I can tell we don't need
any heuristics here, we know exactly which slots are affected.

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

show more ...

[StackColoring] Fix typo in comment

[MachineFunction][DebugInfo][nfc] Introduce EntryValue variable kind

MachineFunction keeps a table of variables whose addresses never change
throughout the function. Today, the only kinds of locatio

[MachineFunction][DebugInfo][nfc] Introduce EntryValue variable kind

MachineFunction keeps a table of variables whose addresses never change
throughout the function. Today, the only kinds of locations it can
handle are stack slots.

However, we could expand this for variables whose address is derived
from the value a register had upon function entry. One case where this
happens is with variables alive across coroutine funclets: these can
be placed in a coroutine frame object whose pointer is placed in a
register that is an argument to coroutine funclets.

```
define @foo(ptr %frame_ptr) {
dbg.declare(%frame_ptr, !some_var,
!DIExpression(EntryValue, <ptr_arithmetic>))
```

This is a patch in a series that aims to improve the debug information
generated by the CoroSplit pass in the context of `swiftasync`
arguments. Variables stored in the coroutine frame _must_ be described
the entry_value of the ABI-defined register containing a pointer to the
coroutine frame. Since these variables have a single location throughout
their lifetime, they are candidates for being stored in the
MachineFunction table.

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

show more ...

Fix uninitialized pointer members in CodeGen

This change initializes the members TSI, LI, DT, PSI, and ORE pointer feilds of the SelectOptimize class to nullptr.

Reviewed By: LuoYuanke

Differentia

Fix uninitialized pointer members in CodeGen

This change initializes the members TSI, LI, DT, PSI, and ORE pointer feilds of the SelectOptimize class to nullptr.

Reviewed By: LuoYuanke

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

show more ...

[StackColoring] Don't merge slots with differing StackIDs

The documentation for this specifically mentions that this should not
happen. We could think about adding target hooks to permit it (and how

[StackColoring] Don't merge slots with differing StackIDs

The documentation for this specifically mentions that this should not
happen. We could think about adding target hooks to permit it (and how
to merge IDs) in the future if that is desirable.

This specific test case was merging a scalable-vector slot into a
non-scalable one and dropping the notion of scalability, meaning we
failed to allocate enough stack space for the object.

Reviewed By: arsenm, MaskRay, sdesmalen

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

show more ...

Fix warnings about variables that are set but only used in debug mode

Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.

Diff

Fix warnings about variables that are set but only used in debug mode

Add void casts to mark the variables used, next to the places where
they are used in assert or `LLVM_DEBUG()` expressions.

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

show more ...

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

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

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

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

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...

Cleanup codegen includes

after: 1061034926
before: 1063332844

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

[StackColoring] Fix a debug invariance problem

Ignore dbg instructions when collecting stack slot markers. This is
to make sure the coloring is invariant regarding presence of dbg
instructions (even

[StackColoring] Fix a debug invariance problem

Ignore dbg instructions when collecting stack slot markers. This is
to make sure the coloring is invariant regarding presence of dbg
instructions (even in cases when the dbg instructions might be
badly placed in the input).

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

show more ...

[CodeGen] Use range-based for loops (NFC)

[NFC] Fix typo in comment.

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