[LLVMdev] Disabling certain optimizations at -O1?

[Chris Lattner]

On Nov 26, 2013, at 8:59 AM, Reid Kleckner <rnk at google.com> wrote:

> 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.

I agree,

-Chris

> 
> 
> On Tue, Nov 26, 2013 at 3:57 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote:
> Hi,
> 
> there are optimizations, mostly dealing with hoisting/merging common
> code including function calls, that breaks stack trace symbolization
> in a very bad way.
> 
> int f(int x) {
>   if (x == 1)
>     report("a");
>   else if (x == 2)
>     report("b");
>   return 0;
> }
> 
> For example, in the above function (at -O1) both calls to report() are
> done from the same PC. As a result, stack trace (from inside report())
> will point to the same source line no matter what branch was actually
> taken. In practice, these two (or more) lines may be very far from
> each other. This makes stack traces misleading and very hard to reason
> about.
> 
> Mostly, we are running in this issue with sanitizers, where we care
> about performance (and therefore don't use -O0), but want stacktraces
> to be mostly sane anyway.
> 
> http://llvm-reviews.chandlerc.com/D2214
> http://llvm-reviews.chandlerc.com/D2215
> 
> I've prepared two patches that deal with these issues by disabling
> this and similar optimizations when building with sanitizers.
> 
> Would it be reasonable to disable these optimizations at -O1 instead?
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131126/f5bc3cc9/attachment.html>