Displaying 6 results from an estimated 6 matches for "dbg_phi".
2020 Sep 09
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
...f
compilation by using the SSA-like information from instruction
referencing. Here's the MIR for the reduced loop body, using
instruction-referencing [1] and lightly edited to remove noise, with
only variable locations for the 'i' variable. I've added some
explanatory comments:
DBG_PHI $rbx, 2
DBG_INSTR_REF 2, 0, !16, !DIExpression(), debug-location !23
; This is the load from *curptr:
renamable $rdi = MOV64rm renamable $r15, 8, renamable $rbx
; Call to ext,
CALL64pcrel32 @ext, csr_64, [implicit defs]
; Loop increment:
renamable $rbx = nuw nsw ADD64ri...
2020 Feb 25
2
[RFC] DebugInfo: A different way of specifying variable locations post-isel
...t to the truth.
>
> Oh, you answer this here. So LiveDebugVariables would need to figure out, for each debug-use-of-phi, 1) which block to put it in and 2) which register+variable gets defined. This is different enough from the new-style debug instr to potentially warrant its own instruction (DBG_PHI?).
Yes and no; I think 1) should be un-necessary, or at least not be
difficult in any way. The DBG_PHIs would refer to a block and
register, identifying the PHIs value at a single program location, the
start of the block where it is defined. This is (98% certain) easy to
identify in virtregrewrite...
2020 Sep 08
2
[RFC] [DebugInfo] Using DW_OP_entry_value within LLVM IR
Hi Djordje,
[Late reply as I was away, alas],
For the example in https://reviews.llvm.org/D85012 , I'm not sure that
just using an entry value is correct. The reason why the dbg.values
for arguments are set to undef is not because the value can't be
described, it's because deadargelim changes all the call sites to pass
in 'undef', which I believe makes the value unrecoverable
2020 Nov 06
2
[DebugInfo] A value-tracking variable location update
...e because the COPY doesn't actually define a value, it just moves
it between locations. At least one optimisation (X86 LEAtoMOV) transforms
instructions into COPYs (LEA $rsp + 0 => COPY $rsp), which is unfortunate.
This doesn't happen a lot though, and can be fixed by dropping a DBG_PHI
of the COPYd register nearby. Plus it only happens post-regalloc, which
makes it less of a problem.
* Trivial def rematerialization: there's no pattern to rely on in how the
register allocator rematerializes values, and so values can rematerialize
in different registers dominating...
2020 Nov 06
0
[DebugInfo] A value-tracking variable location update
...OPY doesn't actually define a value, it just moves
> it between locations. At least one optimisation (X86 LEAtoMOV) transforms
> instructions into COPYs (LEA $rsp + 0 => COPY $rsp), which is unfortunate.
> This doesn't happen a lot though, and can be fixed by dropping a DBG_PHI
> of the COPYd register nearby. Plus it only happens post-regalloc, which
> makes it less of a problem.
> * Trivial def rematerialization: there's no pattern to rely on in how the
> register allocator rematerializes values, and so values can rematerialize
> in differ...
2020 Feb 24
5
[RFC] DebugInfo: A different way of specifying variable locations post-isel
Hi debuginfo cabal,
tl;dr: I'd like to know what people think about an alternative to
DBG_VALUE instructions describing variable locations in registers,
virtual or real. Before instruction selection in LLVM-IR we identify
the _values_ of variables [0] by the instruction that computes the
value; I believe we should be able to do the same post-isel, and it
would avoid having to analyse register