[llvm-bugs] [Bug 44117] New: [DebugInfo at O2] MachineSink can unsoundly extend variable location ranges

[via llvm-bugs]

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

            Bug ID: 44117
           Summary: [DebugInfo at O2] MachineSink can unsoundly extend
                    variable location ranges
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: aprantl at apple.com, chackz0x12 at gmail.com,
                    greg.bedwell at sony.com, llvm-bugs at lists.llvm.org,
                    orlando.hyams at sony.com, paul.robinson at am.sony.com,
                    stephen.tozer at sony.com, vsk at apple.com
            Blocks: 38768

This is a bug report to document an edge case to do with the machine-sink pass
that I don't think can be easily solved.

Here's a highly contrived reproducer, that when compiled with trunk "-O2 -g -c
-fno-unroll-loops" will sink the computation of "a & 0xFFFF" into the final
block (where there's the assign to global). It also sinks the (salvaged)
DBG_VALUE for the first value of "badgers" too.

--------8<--------
int global, global2;

int
foo(int a, int b)
{
  int floogie = a & 0xFFFF;
  int badgers = floogie + 12;

  if (a == 1234567) {
    badgers = global2; // body uninteresting, but "badgers" reassigned
    badgers ^= a;
    global2 = badgers + 1;
    if (b == 12)
      return global;
  }

  global = floogie;
  return global;
}
-------->8--------

Normally, in the end block, we would not be able to compute a location for
"badgers", because we don't know which side of the "a == 1234567" condition was
taken. The location would be empty / optimised out.

However, because the DBG_VALUE for "badgers" sinks into that end block, it
specifies the variable location as being "floogie+12", regardless of which side
of the condition was taken, which is not a true representation of the original
program.

This is actually really hard to solve with our current model. If there were no
further assignments to "badgers" on any path from the source to destination
block, then the DBG_VALUE sinking would be absolutely fine and desirable.
However, discovering whether this is true or not involves examining every block
that _might_ be on a path from the source to the destination position, which
AFAIUI is expensive. Machine sinking doesn't currently do this level of
analysis, so I haven't tried to fix it yet.

This technically applies to any pass that does any kind of sinking. Instcombine
will only sink where there isn't any control flow present though, so this isn't
a problem inscombine currently demonstrates, I think.

Time for Jeremy's pet peeve: in a more ideal world, one where the
machine-location and the instruction-location were separate, we could record an
assignment / location-change in the first block of the program, and the
machine-location in the last block, and leave it to a debug post-processor to
work these things out, when we actually do a full dataflow analysis.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=38768
[Bug 38768] [meta][DebugInfo] Umbrella bug for poor debug experiences
-- 
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/20191122/6a086fbc/attachment.html>