Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was reverted twice, in 987cd7c3ed75b and 13815e8cbf8d4. The latter
stemed from not accounting for rare register classes in a

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was reverted twice, in 987cd7c3ed75b and 13815e8cbf8d4. The latter
stemed from not accounting for rare register classes in a pre-allocated
array, and the former from an array not being completely initialized,
leading to asan complaining.

show more ...

Revert "Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit 5db925023169f8a19419e68153682d1e518f8392.

Further to the early revert, the sanitizers have found so

Revert "Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit 5db925023169f8a19419e68153682d1e518f8392.

Further to the early revert, the sanitizers have found something wrong with
this.

show more ...

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was applied in fda4305e53784, reverted in 13815e8cbf8d49, the problem
was that fp80 X86 registers that were spilt to the sta

Reapply D124184, [DebugInfo][InstrRef] Add a size operand to DBG_PHI

This was applied in fda4305e53784, reverted in 13815e8cbf8d49, the problem
was that fp80 X86 registers that were spilt to the stack aren't expected by
LiveDebugValues. It pre-allocates a position number for all register sizes
that can be spilt, and 80 bits isn't exactly common.

The solution is to scan the register classes to find any unrecognised
register sizes, adn pre-allocate those position numbers, avoiding a later
assertion.

show more ...

Revert "[DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit fda4305e5378478051be225248bfe9c1d401d938.

Green dragon has spotted a problem -- it's understood, but might be fiddly

Revert "[DebugInfo][InstrRef] Add a size operand to DBG_PHI"

This reverts commit fda4305e5378478051be225248bfe9c1d401d938.

Green dragon has spotted a problem -- it's understood, but might be fiddly
to fix, reverting in the meantime.

show more ...

[DebugInfo][InstrRef] Add a size operand to DBG_PHI

DBG_PHI instructions can refer to stack slots, to indicate that multiple
values merge together on control flow joins in that slot. This is fine --

[DebugInfo][InstrRef] Add a size operand to DBG_PHI

DBG_PHI instructions can refer to stack slots, to indicate that multiple
values merge together on control flow joins in that slot. This is fine --
however the slot might be merged at a later date with a slot of a different
size. In doing so, we lose information about the size the eliminated PHI.
Later analysis passes have to guess.

Improve this by attaching an optional "bit size" operand to DBG_PHI, which
only gets added for stack slots, to let us know how large a size the value
on the stack is.

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

show more ...

[DebugInfo][InstrRef][4/4] Support DBG_INSTR_REF through all backend passes

This is a cleanup patch -- we're now able to support all flavours of
variable location in instruction referencing mode. Th

[DebugInfo][InstrRef][4/4] Support DBG_INSTR_REF through all backend passes

This is a cleanup patch -- we're now able to support all flavours of
variable location in instruction referencing mode. This patch updates
various tests for debug instructions to be broader: numerous code paths
try to ignore debug isntructions, and they now have to ignore the
additional DBG_PHI and DBG_INSTR_REFs that we can generate.

A small amount of rework happens for LiveDebugVariables: as we don't need
to track live intervals through regalloc any more, we can get away with
unlinking debug instructions before regalloc, then re-inserting them after.
Note that this isn't (yet) true of DBG_VALUE_LISTs, they still have to go
through live interval tracking.

In SelectionDAG, add a helper lambda that emits half-formed DBG_INSTR_REFs
for arguments in instr-ref mode, DBG_VALUE otherwise. This is one of the
final locations where DBG_VALUEs are emitted for vreg arguments.

X86InstrInfo now un-sets the debug instr number on SUB instructions that
get mutated into CMP instructions. As the instruction no longer computes a
subtraction, we can't use it for variable locations.

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

show more ...

[DebugInstrRef][1/3] Track PHI values through register allocation

This patch introduces "DBG_PHI" instructions, a marker of where a PHI
instruction used to be, before PHI elimination. Under the inst

[DebugInstrRef][1/3] Track PHI values through register allocation

This patch introduces "DBG_PHI" instructions, a marker of where a PHI
instruction used to be, before PHI elimination. Under the instruction
referencing model, we want to know where every value in the function is
defined -- and a PHI, even if implicit, is such a place.

Just like instruction numbers, we can use this to identify a value to be
used as a variable value, but we don't need to know what instruction
defines that value, for example:

bb1:
DBG_PHI $rax, 1
[... more insts ... ]
bb2:
DBG_INSTR_REF 1, 0, !1234, !DIExpression()

This specifies that on entry to bb1, whatever value is in $rax is known
as value number one -- and the later DBG_INSTR_REF marks the position
where variable !1234 should take on value number one.

PHI locations are stored in MachineFunction for the duration of the
regalloc phase in the DebugPHIPositions map. The map is populated by
PHIElimination, and then flushed back into the instruction stream by
virtregrewriter. A small amount of maintenence is needed in
LiveDebugVariables to account for registers being split, but only for
individual positions, not for entire ranges of blocks.

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

show more ...