[LiveDebugValues][InstrRef][2/2] Emit entry value variable locations

This patch adds support to the instruction-referencing LiveDebugValues
implementation for emitting entry values. The instruction

[LiveDebugValues][InstrRef][2/2] Emit entry value variable locations

This patch adds support to the instruction-referencing LiveDebugValues
implementation for emitting entry values. The instruction referencing
implementations tracking by value rather than location means that we can
get around two of the issues with VarLocs. DBG_VALUE instructions that
re-assign the same value to a variable are no longer a problem, because we
can "see through" to the value being assigned. We also don't need to do
anything special during the dataflow stages: the "variable value problem"
doesn't need to know whether a value is available most of the time, and the
times it deoes need to know are always when entry values need to be
terminated.

The patch modifies the "TransferTracker" class, adding methods to identify
when a variable ias an entry value candidate, and when a machine value is
an entry value. recoverAsEntryValue tests these two things and emits an
entry-value expression if they're true. It's used when we clobber or
otherwise lose a value and can't find a replacement location for the value
it contained.

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

show more ...

[LiveDebugValues][InstrRef][1/2] Recover more clobbered variable locations

In various circumstances, when we clobber a register there may be
alternative locations that the value is live in. The clas

[LiveDebugValues][InstrRef][1/2] Recover more clobbered variable locations

In various circumstances, when we clobber a register there may be
alternative locations that the value is live in. The classic example would
be a value loaded from the stack, and then clobbered: the value is still
available on the stack. InstrRefBasedLDV was coping with this at block
starts where it's forced to pick a location, however it wasn't searching
for alternative locations when values were clobbered.

This patch notifies the "Transfer Tracker" object when clobbers occur, and
it's able to find alternatives and issue DBG_VALUEs for that location. See:
the added test.

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

show more ...

Conditionalize function only used in an assert to address -Wunused-function

Catch an extremely obvious memory leak, thanks asan

https://lab.llvm.org/buildbot/#/builders/5/builds/9208

(dbg-phis-merging-in-ldv.mir and dbg-phis-with-loops.mir in the asan
check stage)

[DebugInstrRef][3/3] Follow DBG_PHI instructions through LiveDebugValues

This patch reads machine value numbers from DBG_PHI instructions (marking
where SSA PHIs used to be), and matches them up wit

[DebugInstrRef][3/3] Follow DBG_PHI instructions through LiveDebugValues

This patch reads machine value numbers from DBG_PHI instructions (marking
where SSA PHIs used to be), and matches them up with DBG_INSTR_REF
instructions that refer to them. Essentially they are two separate parts of
a DBG_VALUE: the place to read the value (register and program position),
and where the variable is assigned that value.

Sometimes these DBG_PHIs can be duplicated, usually by tail duplication.
This corresponds to the SSA structure of the program being destroyed, and
the original PHI being split. When this happens: run LLVMs standard
SSAUpdater utility, to work out what values should appear in which blocks.
The majority of this patch is boilerplate to make use of SSAUpdater.

If there are any additional PHIs on the path between multiple DBG_PHIs and
their using DBG_INSTR_REF, their existance is validated, just in case a
value gets clobbered along the way (see dbg-phis-with-loops.mir for
several examples).

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

show more ...

Simplify some typedef struct

[ADT] Make TrackingStatistic's ctor constexpr

This lets clang diagnose unused statistics, so remove them.

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

[llvm] Populate SmallVector at construction time (NFC)

[CodeGen, Transforms] Use llvm::sort (NFC)

[LiveDebugValues] Handle spill locations with a fixed and scalable component.

This patch fixes the two LiveDebugValues implementations
(InstrRef/VarLoc)Based to handle cases where the StackOffset co

[LiveDebugValues] Handle spill locations with a fixed and scalable component.

This patch fixes the two LiveDebugValues implementations
(InstrRef/VarLoc)Based to handle cases where the StackOffset contains
both a fixed and scalable component.

This depends on the `TargetRegisterInfo::prependOffsetExpression` being
added in D90020. Feel free to leave comments on that patch if you have them.

Reviewed By: djtodoro, jmorse

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

show more ...

[Analysis, CodeGen, IR] Use contains (NFC)

Migrate deprecated DebugLoc::get to DILocation::get

This migrates all LLVM (except Kaleidoscope and
CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.

The CodeGen/StackProtector.cpp usag

Migrate deprecated DebugLoc::get to DILocation::get

This migrates all LLVM (except Kaleidoscope and
CodeGen/StackProtector.cpp) DebugLoc::get to DILocation::get.

The CodeGen/StackProtector.cpp usage may have a nullptr Scope
and can trigger an assertion failure, so I don't migrate it.

Reviewed By: #debug-info, dblaikie

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

show more ...

[NFC][IntrRefLDV] Remove dead code from transferSpillOrRestoreInst()

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

[SVE] Return StackOffset for TargetFrameLowering::getFrameIndexReference.

To accommodate frame layouts that have both fixed and scalable objects
on the stack, describing a stack location or offset u

[SVE] Return StackOffset for TargetFrameLowering::getFrameIndexReference.

To accommodate frame layouts that have both fixed and scalable objects
on the stack, describing a stack location or offset using a pointer + uint64_t
is not sufficient. For this reason, we've introduced the StackOffset class,
which models both the fixed- and scalable sized offsets.

The TargetFrameLowering::getFrameIndexReference is made to return a StackOffset,
so that this can be used in other interfaces, such as to eliminate frame indices
in PEI or to emit Debug locations for variables on the stack.

This patch is purely mechanical and doesn't change the behaviour of how
the result of this function is used for fixed-sized offsets. The patch adds
various checks to assert that the offset has no scalable component, as frame
offsets with a scalable component are not yet supported in various places.

Reviewed By: arsenm

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

show more ...

[NFC][IntrRefLDV] Improve the Value printing

Basically, this just improves the dump of the Value stored within a location.

If the defining instruction number is zero, it means it is "live-in".

Bef

[NFC][IntrRefLDV] Improve the Value printing

Basically, this just improves the dump of the Value stored within a location.

If the defining instruction number is zero, it means it is "live-in".

Before the patch:

ESI --> bb 0 inst 0 loc ESI
After:

ESI --> Value{bb: 0, inst: live-in, loc: ESI}
This is an NFC.

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

show more ...

[NFC][IntrRefLDV] Some code clean up

As reading the source code, I've found some minor nits:
-Use using instead of typedef
-Fix a comment
-Refactor

Differential Revision: https://reviews.llvm

[NFC][IntrRefLDV] Some code clean up

As reading the source code, I've found some minor nits:
-Use using instead of typedef
-Fix a comment
-Refactor

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

show more ...

[NFC][InstrRefLDV] Fix a typo

[DebugInstrRef] Handle DBG_INSTR_REFs use-before-defs in LiveDebugValues

Deciding where to place debugging instructions when normal instructions
sink between blocks is difficult -- see PR44117. Deal

[DebugInstrRef] Handle DBG_INSTR_REFs use-before-defs in LiveDebugValues

Deciding where to place debugging instructions when normal instructions
sink between blocks is difficult -- see PR44117. Dealing with this with
instruction-referencing variable locations is simple: we just tolerate
DBG_INSTR_REFs referring to values that haven't been computed yet. This
patch adds support into InstrRefBasedLDV to record when a variable value
appears in the middle of a block, and should have a DBG_VALUE added when it
appears (a debug use before def).

While described simply, this relies heavily on the value-propagation
algorithm in InstrRefBasedLDV. The implementation doesn't attempt to verify
the location of a value unless something non-trivial occurs to merge
variable values in vlocJoin. This means that a variable with a value that
has no location can retain it across all control flow (including loops).
It's only when another debug instruction specifies a different variable
value that we have to check, and find there's no location.

This property means that if a machine value is defined in a block dominated
by a DBG_INSTR_REF that refers to it, all the successor blocks can
automatically find a location for that value (if it's not clobbered). Thus
in a sense, InstrRefBasedLDV is already supporting and implementing
use-before-defs. This patch allows us to specify a variable location in the
block where it's defined.

When loading live-in variable locations, TransferTracker currently discards
those where it can't find a location for the variable value. However, we
can tell from the machine value number whether the value is defined in this
block. If it is, add it to a set of use-before-def records. Then, once the
relevant instruction has been processed, emit a DBG_VALUE immediately after
it.

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

show more ...

[DebugInstrRef] Convert DBG_INSTR_REFs into variable locations

Handle DBG_INSTR_REF instructions in LiveDebugValues, to determine and
propagate variable locations. The logic is fairly straight forwa

[DebugInstrRef] Convert DBG_INSTR_REFs into variable locations

Handle DBG_INSTR_REF instructions in LiveDebugValues, to determine and
propagate variable locations. The logic is fairly straight forwards:
Collect a map of debug-instruction-number to the machine value numbers
generated in the first walk through the function. When building the
variable value transfer function and we see a DBG_INSTR_REF, look up the
instruction it refers to, and pick the machine value number it generates,
That's it; the rest of LiveDebugValues continues as normal.

Awkwardly, there are two kinds of instruction numbering happening here: the
offset into the block (which is how machine value numbers are determined),
and the numbers that we label instructions with when generating
DBG_INSTR_REFs.

I've also restructured the TransferTracker redefVar code a little, to
separate some DBG_VALUE specific operations into its own method. The
changes around redefVar should be largely NFC, while allowing
DBG_INSTR_REFs to specify a value number rather than just a location.

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

show more ...

[DebugInstrRef] NFC: Separate collection of machine/variable values

This patch adjusts _when_ something happens in LiveDebugValues /
InstrRefBasedLDV, to make it more amenable to dealing with DBG_IN

[DebugInstrRef] NFC: Separate collection of machine/variable values

This patch adjusts _when_ something happens in LiveDebugValues /
InstrRefBasedLDV, to make it more amenable to dealing with DBG_INSTR_REF
instructions. There's no functional change.

In the current InstrRefBasedLDV implementation, we collect the machine
value-number transfer function for blocks at the same time as the
variable-value transfer function. After solving machine value numbers, the
variable-value transfer function is updated so that DBG_VALUEs of live-in
registers have the correct value. The same would need to be done for
DBG_INSTR_REFs, to connect instruction-references with machine value
numbers.

Rather than writing more code for that, this patch separates the two: we
collect the (machine-value-number) transfer function and solve for
machine value numbers, then step through the MachineInstrs again collecting
the variable value transfer function. This simplifies things for the new
few patches.

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

show more ...

[NFC] Set return type of getStackPointerRegisterToSaveRestore to Register

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

[LiveDebugValues] Add `#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)` to suppress -Wunused-function

[LiveDebugValues][NFC] Re-land 60db26a66d, add instr-ref tests

This was landed but reverted in 5b9c2b1bea7 due to asan picking up a memory
leak. This is fixed in the change to InstrRefBasedImpl.cpp.

[LiveDebugValues][NFC] Re-land 60db26a66d, add instr-ref tests

This was landed but reverted in 5b9c2b1bea7 due to asan picking up a memory
leak. This is fixed in the change to InstrRefBasedImpl.cpp. Original
commit message follows:

[LiveDebugValues][NFC] Add instr-ref tests, adapt old tests

This patch adds a few tests in DebugInfo/MIR/InstrRef/ of interesting
behaviour that the instruction referencing implementation of
LiveDebugValues has. Mostly, these tests exist to ensure that if you
give the "-experimental-debug-variable-locations" command line switch,
the right implementation runs; and to ensure it behaves the same way as
the VarLoc LiveDebugValues implementation.

I've also touched roughly 30 other tests, purely to make the tests less
rigid about what output to accept. DBG_VALUE instructions are usually
printed with a trailing !debug-location indicating its scope:

!debug-location !1234

However InstrRefBasedLDV produces new DebugLoc instances on the fly,
meaning there sometimes isn't a numbered node when they're printed,
making the output:

!debug-location !DILocation(line: 0, blah blah)

Which causes a ton of these tests to fail. This patch removes checks for
that final part of each DBG_VALUE instruction. None of them appear to
be actually checking the scope is correct, just that it's present, so
I don't believe there's any loss in coverage here.

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

show more ...

Fix Wdocumentation warning. NFCI.

Remove \returns tag from a void function