[llvm-bugs] [Bug 31891] New: Stripping location information off of hoisted readnone calls conflicts with DI verification assertions for inlinable calls

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Feb 7 09:09:08 PST 2017


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

            Bug ID: 31891
           Summary: Stripping location information off of hoisted readnone
                    calls conflicts with DI verification assertions for
                    inlinable calls
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: DebugInfo
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Recently r294250 / https://reviews.llvm.org/D29377 made GVNHoist use
DILocation::getMergedLocation. By design, getMergedLocation appears to return
null when the two locations are sufficiently different that preserving one or
the other would produce a "jumpy" line table.

Unfortunately, if the instruction being hoisted is an inlinable call, this
conflicts with the verifier's assertions that require accurate scope
information on inlinable calls. Typically a call can be hoisted if it is
readnone, i.e. it is a pure function of its arguments.

Consider:

$ cat t.c
void useit1(float);
void useit2(float);
double fabs(double);
float fabsf(float f) {
  return (float)fabs((double)f);
}
void hoistit(int cond, float f) {
  if (cond) {
    useit1(fabsf(f));
  } else {
    useit2(fabsf(f));
  }
}

$ clang -S t.c -o - -emit-llvm -g | opt -functionattrs -gvn-hoist -S
inlinable function call in a function with debug info must have a !dbg location
  %call = call float @fabsf(float %1) #1
LLVM ERROR: Broken function found, compilation aborted!

If I revert r294250, we leave the location of the first call to fabsf, and the
problem goes away.

I'm filing the bug rather than simply reverting because this seems to raise a
higher level design question about stripping location information when
hoisting.

-- 
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/20170207/b9f89308/attachment.html>


More information about the llvm-bugs mailing list