[llvm-bugs] [Bug 50072] New: Incorrect debug information with stack slot sharing

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50072

            Bug ID: 50072
           Summary: Incorrect debug information with stack slot sharing
           Product: new-bugs
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: markus.lavin at ericsson.com
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Consider
---
void consume(int *in);
int *getptr();

static inline void force_spill() {
  __asm volatile(""
                 :
                 :
                 : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "r8", "r9",
                   "r10", "r11", "r12", "r14", "r15");
}

void spill() {
#pragma nounroll
  for (int i = 0; i < 16; ++i) {
    int *p = getptr();
    force_spill();
    consume(p);
    int *q = getptr();
    force_spill();
    consume(q);
  }
}
---
compiling with

$ clang -g -O3 spill-arm.c --target=arm-linux-gnu -mfloat-abi=soft -S

Now variables 'p' and 'q' will be spilled to stack slots between the calls to
'getptr' and 'consume'. Since these two variables are not live at the same time
the stack slots can be shared and the 'stack-slot-coloring' pass merges them
into the same stack slot. This is all fine but when looking at the final debug
info in 'spill-arm.s' we can see that the location range for 'p' overlaps that
of 'q'. This is clearly incorrect as it will result in the debugger showing the
value of 'q' for 'p' when 'q' is live.

.Ldebug_loc0: // for 'p'
  .long   .Ltmp3-.Lfunc_begin0
  .long   .Ltmp12-.Lfunc_begin0
.Ldebug_loc1: // for 'q'
  .long   .Ltmp7-.Lfunc_begin0
  .long   .Ltmp12-.Lfunc_begin0

The expected behavior would have been for the range for 'p' to end when the
range for 'q' begins (so that the debugger would have shown '<optimized-out>'
for 'p' when 'q' is live).

To me it seems that this could be addressed in 'stack-slot-coloring' by
inserting a 'DBG_VALUE $noreg, ..., "p"' at the point where 'q' is merged into
the slot of 'p'. But I am not really sure of the semantics of DBG_VALUE at this
point in the pipeline so perhaps it should be addressed elsewhere
(DbgEntityHistoryCalculator.cpp?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210422/ceaa6091/attachment.html>