<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Nov 26, 2013, at 8:59 AM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I'd support disabling tail merging of calls at -O1. The other CFG simplification doesn't seem like that big of a deal though for general debugging, though.</div></blockquote><div><br></div>I agree,</div><div><br></div><div>-Chris</div><div><br><blockquote type="cite"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Nov 26, 2013 at 3:57 AM, Evgeniy Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
there are optimizations, mostly dealing with hoisting/merging common<br>
code including function calls, that breaks stack trace symbolization<br>
in a very bad way.<br>
<br>
int f(int x) {<br>
if (x == 1)<br>
report("a");<br>
else if (x == 2)<br>
report("b");<br>
return 0;<br>
}<br>
<br>
For example, in the above function (at -O1) both calls to report() are<br>
done from the same PC. As a result, stack trace (from inside report())<br>
will point to the same source line no matter what branch was actually<br>
taken. In practice, these two (or more) lines may be very far from<br>
each other. This makes stack traces misleading and very hard to reason<br>
about.<br>
<br>
Mostly, we are running in this issue with sanitizers, where we care<br>
about performance (and therefore don't use -O0), but want stacktraces<br>
to be mostly sane anyway.<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D2214" target="_blank">http://llvm-reviews.chandlerc.com/D2214</a><br>
<a href="http://llvm-reviews.chandlerc.com/D2215" target="_blank">http://llvm-reviews.chandlerc.com/D2215</a><br>
<br>
I've prepared two patches that deal with these issues by disabling<br>
this and similar optimizations when building with sanitizers.<br>
<br>
Would it be reasonable to disable these optimizations at -O1 instead?<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>