similar to: [LLVMdev] Disabling certain optimizations at -O1?

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

On 26 November 2013 16:59, 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. > So, do we have two ways of running SimplifyCFG? One for O1 and one for O2+, and selectively disabling parts of it? --renato --------------

On 11/26/13 3:57 AM, Evgeniy Stepanov 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; > } >

On 2 December 2013 20:12, Philip Reames <listmail at philipreames.com> wrote: > Would it make sense to separate our a flag for preserving full and exactly > stack traces? Using -O1 is one option, but it would be nice to move beyond > -O1 with reasonable confidence that stack traces would be preserved. Would > others be interested in such a feature? I can't say I'm

Renato, I'm not sure I follow. By #pragma, do you mean a C-level thing? By table of flags, some hypothetical place where the proposed "Simple|Speed|Space|Aggressive" setting lives, accessible by IR passes? Sounds like what Philip needs is a more specific PreserveStackTraces setting in the same place, that's on by default at -O1, and overridable by some find of

Reid, by the other CFG simplification, do you mean this case in http://llvm-reviews.chandlerc.com/D2214? 1: if (x < 0) 2: if (y < 0) 3: do_something(); Yes, this is only bad for MSan (and probably for sampling-based PGO, but that's a whole different story). But the current version of D2214 disables this optimization at SimplifyUncondBranch() point, which also covers

Could we move this setting to function attributes? We already have OptimizeForSize / MinSize there, but not the other opt levels. We also have OptimizeNone, which seems to be completely unused. This would let us support __attribute__((optimize())) in the future, which is currently ignored. Another example would be an LTO link of objects compiled with different optimization settings. I'm not

On 1 December 2013 10:44, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > Could we move this setting to function attributes? I think this is a good idea. > This would let us support __attribute__((optimize())) in the future, > which is currently ignored. I'm adding #pragma vectorize enable which does more or less the same thing as

On Tue, Nov 19, 2013 at 9:05 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > My $0.02 - I'm not sure the transformation introduces a data race. > > To the best of my understanding, the point of the C++11/C11 memory model > is to allow a wide array of compiler transformations - including > speculative loads - for non-atomic variables. > I believe

On 27 November 2013 08:43, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > Also note that tail merging of calls happens in CodeGen, not in > SimplifyCFG. > Hi Evgenly, What we need is the general information that we want to avoid too much code motion, from choosing the passes, to choosing steps on the passes, to lowering code differently. On the front-end layer, It's

AFAIU, it's not OK for -g to affect code generation. I agree with the rest of your plan. On Wed, Nov 27, 2013 at 2:16 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 27 November 2013 08:43, Evgeniy Stepanov <eugeni.stepanov at gmail.com> > wrote: >> >> Also note that tail merging of calls happens in CodeGen, not in >> SimplifyCFG. > > >

> AFAIU, it's not OK for -g to affect code generation. I agree with the > rest of your plan. That's correct, -g must not affect code generation. This is a fundamental mantra among debug-info people. > > > On Wed, Nov 27, 2013 at 2:16 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 27 November 2013 08:43, Evgeniy Stepanov >

What I'm trying to say is that according to my understanding of the C++11 memory model, even in that small reproducer, the store to g and the load from g are in fact a data race. (This is regardless of the fact the load is protected by a branch that is not taken.) From: Kostya Serebryany [mailto:kcc at google.com] Sent: Tuesday, November 19, 2013 19:46 To: Kuperstein, Michael M Cc: Evgeniy

The root cause of those issues is the fact that sanitizers verify C++-level semantics with LLVM IR level instrumentation. For example, speculative loads are OK in IR if it can be proved that the load won't trap, but in C++ it would be a data race. On Tue, Nov 19, 2013 at 8:38 PM, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Nov 19, 2013 at 8:25 PM, David

On 27 November 2013 19:36, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote: > That's correct, -g must not affect code generation. This is a > fundamental mantra among debug-info people. I think you both got me on the wrong side, though I admit my email wasn't clear. I didn't mean to suggest changing codegen for debug purposes only, but on -O1 to be less

On Tue, Nov 19, 2013 at 10:08 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Kostya Serebryany" <kcc at google.com> > > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Tuesday, November 19,

My $0.02 - I'm not sure the transformation introduces a data race. To the best of my understanding, the point of the C++11/C11 memory model is to allow a wide array of compiler transformations - including speculative loads - for non-atomic variables. I believe what's most likely happening (without looking at the Mozilla source) is that the original program contains a C++ data race, and

Just moving this branch of the thread out of the review because I don't want to derail the review thread... Kostya - why are these two cases not optimization bugs in general? (why do they only affect sanitizers?) On Mon, Nov 18, 2013 at 8:37 PM, Kostya Serebryany <kcc at google.com> wrote: > And we've been just informed by the mozilla folks about yet another case > of

----- Original Message ----- > From: "Kostya Serebryany" <kcc at google.com> > To: "Michael M Kuperstein" <michael.m.kuperstein at intel.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Tuesday, November 19, 2013 11:45:39 AM > Subject: Re: [LLVMdev] Curiosity about transform changes under Sanitizers (Was:

On Tue, Nov 19, 2013 at 9:56 PM, Kuperstein, Michael M < michael.m.kuperstein at intel.com> wrote: > What I’m trying to say is that according to my understanding of the > C++11 memory model, even in that small reproducer, the store to g and the > load from g are in fact a data race. > > (This is regardless of the fact the load is protected by a branch that is > not