[llvm-bugs] [Bug 40628] [DebugInfo at O2] Salvaged memory loads can observe subsequent memory writes

[via llvm-bugs]

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

Jeremy Morse <jeremy.morse.llvm at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|CONFIRMED                   |RESOLVED
 Fixed By Commit(s)|                            |353824

--- Comment #1 from Jeremy Morse <jeremy.morse.llvm at gmail.com> ---
Fix review is in https://reviews.llvm.org/D57962, committed in r353824, I'm
copy&pasting an example from the review here so that future archaeologists have
examples all in one place:

[...] I think the greater issue is that with DW_OP_derefs present it's
difficult to determine when code movement in optimisation passes affects
dbg.values. Consider this example, compiling "-O2 -g -fno-inline
-fno-unroll-loops" with clang at r353515:

static int qux[] = { 1, 2, 3, 4 };

int
foo(int baz, int *out)
{
  int sum = 0;
  for (int i = 0; i < 4; i++) {
    int extra = *out;
    sum += qux[i] * baz;
    sum %= 4;
    *out = sum;
  }
  return sum;
}

int
main(int argc, char **argv)
{
  int out = 12;
  return foo(argc, &out);
}

(The assign to 'extra' is contrived but eliminating loads is something LLVM
does all the time I believe). In this code, LICM promotes '*out' to an SSA
register for the body of the loop. However, before LICM the dbg.value for
'extra' has its load operand folded into a DW_OP_deref, and points at the
variable in 'main'. Stepping through this program in gdb, 'extra' always reads
as '12', rather than any of the values computed in the loop. Invalidating the
dbg.value at the next memory store wouldn't help, as the location specified by
the dbg.value never holds the value we're interested in.

My main point here is that not only would LICM need to be taught that moving
the store to '*out' could invalidate some dbg.values, determining which
dbg.values are affected would involve digging into DIExpressions looking for
dereferences, potentially through GEPs that were folded in too, possibly even
requiring alias analysis on any dbg.value with a deref. Which (as far as I'm
aware) is a reasonably large amount of code complexity and computation.
DeadStoreElimination would need to behave similarly (a dbg.value might try to
point at the memory of a store that's later eliminated).

-- 
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/20190212/69ec285f/attachment.html>