[llvm-bugs] [Bug 39786] New: [DebugInfo at O2] InstCombine pointer type-cast sinking needlessly reduces dbg location ranges

[via llvm-bugs]

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

            Bug ID: 39786
           Summary: [DebugInfo at O2] InstCombine pointer type-cast sinking
                    needlessly reduces dbg location ranges
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: CONFIRMED
          Keywords: wrong-debug
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: jeremy.morse.llvm at gmail.com
                CC: chackz0x12 at gmail.com, dblaikie at gmail.com,
                    greg.bedwell at sony.com,
                    international.phantom at gmail.com,
                    llvm-bugs at lists.llvm.org, paul.robinson at am.sony.com
            Blocks: 38768

The example program at the bottom of this bug report, using llvm r346686 with
options "-O2 -g", demonstrates an example of pointer-typing gratuitously
reducing the availability of variable locations. Specifically, the "xyzzy"
pointer of "main" isn't visible except for the line "((baz | qux) & 0xaaaaaa) %
199" in the "something" method, despite being alive all the way up to that
point. The same for the "this" pointer of "something".

The example code is extremely cooked as I was trying to replicate a fault in
bug 38754, when reading it ignore any arithmetic expressions (they're there to
defeat SimplifyCFG speculation) and consider only accesses to memory / object
members. I've also sprinkled "volatile" to prevent further optimisations of
some parts.

Essentially: the whole file gets inlined into the main function, and optimisers
determine that the object pointer that's been allocated isn't needed for the
"foo" and "bar" members of "xyzzy", they spend their lifetimes in SSA
registers. That pointer is then only needed for the writes and reads of "baz"
and "qux" because they're volatile. This causes InstCombine to sink the i8* to
%class.trains* bitcast instruction for "xyzzy" into the BB for the first return
statement in "something", because nothing else uses it. It also sinks the
dbg.value for "xyzzy", to prevent use-before-free of the bitcast.

This is a totally valid optimisation, and a totally valid prevention of
use-before-free, but the net effect is that the developer can't inspect the
object they just allocated (in the "main" function, or the start of the
"something" function). Given that the pointer has to be live up til the middle
of the "something" method, that's particularly upsetting.

As with bug 39726, the use of a typed pointer artificially makes it look like
the dbg.value for xyzzy must be sunk, wheras at the machine level that's not
the case. (More generally maybe InstCombine should be leaving a
dbg.value(undef...) around to prevent earlier variable locations leaking, but
I'll fry that fish some other day).

--------8<--------
#include <stdlib.h>

class trains {
public:
  int foo;
  int bar;
  volatile int baz;
  volatile int qux;
  trains() {
    foo = 1; bar = 2;
    baz = 3; qux = 4;
  }

  __attribute__((always_inline)) int something() {
    volatile int quux = foo + bar;
    if (quux > 0)
      return ((baz | qux) & 0xaaaaaa) % 199;
    else {
      if (quux > 10000) 
        abort();
      return (foo * bar) % 200;
    }
  }
};

__attribute__((always_inline)) trains *alloc() {
  volatile int foo = 0;
  auto *p = new trains();
  if (foo != 0)
    abort();
  return p;
}

int main() {
  int toreturn = 0;
  if (auto xyzzy = alloc()) {
    toreturn = xyzzy->something();
  }
  return toreturn;
}
-------->8--------


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/20181126/ac9d6661/attachment.html>