search for: dbg_instr_ref

...ng 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 ADD64ri8 killed renamable $rbx, 1...

...a critical feature (it isn't today), as we would no longer generate > > stack locations during register allocation. > > Do you expect that handling for the current and new-style DBG_VALUEs could coexist in LiveDebugValues? Could that be done by e.g. introducing a new debug instr MI (DBG_INSTR_REF)? I believe it should be relatively straightforwards: we would have an additional kind of location-record (i.e. VarLoc) that, instead of identifying a _variable_, identified the instruction/operand that computed a value. Handling a DBG_INSTR_REF as you suggest would mean looking up such a VarLoc b...

....e. clobbered), control flow joins are a simple matter of "Do the predecessors agree on the location?", and not much more work is needed. Switching to tracking variable values is more complicated. Following the original proposal, for this pseudo-MIR code sequence: $rax = somedef DBG_INSTR_REF reference-to-somedef $rbx = COPY killed $rax ; Variable location is $rax, then moves to $rbx We need to track that: a) $rax contains a value defined by the "somedef" instruction, b) The DBG_INSTR_REF needs a location for the value somedef defines. c) That value from "some...

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

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