[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

Follow-up build fix for rGae6f78824031

One of the bots objects to brace-initializing a tuple:

http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/43595/steps/build%20stag

Follow-up build fix for rGae6f78824031

One of the bots objects to brace-initializing a tuple:

http://lab.llvm.org:8011/builders/clang-cmake-x86_64-sde-avx512-linux/builds/43595/steps/build%20stage%201/logs/stdio

As the tuple constructor is apparently explicit. Fall back to the (not
as pretty) explicit construction of a tuple. I'd thought this was
permitted behaviour; will investigate why this fails later.

show more ...

[LiveDebugValues] Delete unneeded copy constructor after D83047

It will suppress the implicitly-declared copy assignment operator in C++20.

[LiveDebugValues] Add instruction-referencing LDV implementation

This patch imports the instruction-referencing implementation of
LiveDebugValues proposed here:

http://lists.llvm.org/pipermail/ll

[LiveDebugValues] Add instruction-referencing LDV implementation

This patch imports the instruction-referencing implementation of
LiveDebugValues proposed here:

http://lists.llvm.org/pipermail/llvm-dev/2020-June/142368.html

The new implementation is unreachable in this patch, it's the next patch
that enables it behind a command line switch. Briefly, rather than
tracking variable locations by just their location as the 'VarLoc'
implementation does, this implementation does it by value:
* Each value defined in a function is numbered, and propagated through
dataflow,
* Each DBG_VALUE reads a machine value number from a machine location,
* Variable _values_ are propagated through dataflow,
* Variable values are translated back into locations, DBG_VALUEs
inserted to specify where those locations are.

The ultimate aim of this is to enable referring to variable values
throughout post-isel code, rather than locations. Those patches will
build on top of this new LiveDebugValues implementation in later patches
-- it can't be done with the VarLoc implementation as we don't have
value information, only locations.

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

show more ...