[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