https://bugs.llvm.org/show_bug.cgi?id=44117
Bug ID: 44117
Summary: [DebugInfo@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: unassignedb...@nondot.org
Reporter: jeremy.morse.l...@gmail.com
CC: apra...@apple.com, chackz0...@gmail.com,
greg.bedw...@sony.com, llvm-bugs@lists.llvm.org,
orlando.hy...@sony.com, paul.robin...@am.sony.com,
stephen.to...@sony.com, v...@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
