[LLVMdev] Disabling certain optimizations at -O1?

[Robinson, Paul]

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: Wednesday, November 27, 2013 12:02 PM
> To: Robinson, Paul
> Cc: Evgeniy Stepanov; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Disabling certain optimizations at -O1?
> 
> 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 aggressive on some parts than it
> is today. Some flag saying "optimize-for-debug".

Ah, okay.  Sounds good.

> 
> It's not easy to know what kind of optimization you can do that won't
> change how the program runs, and thus changing how the program breaks,

Any optimization ought to preserve the overall behavior of the program.
The point where optimizations interfere with debugging is when they take
a simple mapping of instructions/values back to source code, and make
that mapping more complicated.  When is it "too" complicated? That's not
a completely heuristic question, although it is too large a question to
get into here.  In my experience, to a first approximation, anything 
that changes the CFG or that reorders generated code beyond source
statement boundaries is likely to make things more difficult for the 
debugger.

> so maybe the -g special flag was a bad idea to begin with. But the
> need to make -O1 be debuggable could very well be the just the thing I
> needed to give names to the optimization options.
> 
> Earlier this year I proposed we have names, rather than numbers, that
> would represent our optimization levels:
> 
> 0 = Debug
> 1 = FastDebug
> 2 = Speed
> 3 = Aggressive
> S = Space
> Z = SpaceAggressive
> 
> I'm assuming there is little value in -O1 than just a faster debug
> experience, so why not make it take decisions on the debug illusion as
> well? Ie. ignore my -g/-O1 dependency I proposed.

Okay.  I worked on compilers where -O1 was the default, actually, and
it was "generally fast enough" but still very easy to produce very
good debug info.

> 
> 
> > Intuitively I'd expect that the set of passes to be run would vary
> with
> > opt level, and much less often would a pass want to vary its behavior
> > according to opt level.  But "much less often" isn't "never" and so it
> > seems very weird that a pass wouldn't know the opt level.
> 
> As far as I know (and I may be wrong), the passes only have access to
> things like "optimize-for-space/speed".
> 
> Because optimization levels don't mean anything concrete, it'd be a
> bit silly to have an "if (opt == 3) do this" in a pass.

Hm okay, I could see that passes would rather have some kind of more
semantically significant criteria.

> 
> 
> > Some indication of "be sanitizer/debugger friendly" that can guide
> > pass internal behavior seems like a good plan.  I had this in a
> previous
> > compiler I worked on, and it was extremely helpful in producing code
> > that was easy to debug.
> 
> That's the plan.
> 
> If the optimization levels (at least in LLVM) have names, we can
> easily make -OFastDebug and -ODebug have the same "debug" flag set,
> and so on.
> 
> enum OptLevel {
>   Debug = 1, // Debug Illusion
>   Speed = 2, // Performance
>   Space = 4, // Size
>   Aggressive = 8,
> }
> 
> -O0 = Debug
> -O1 = Debug+Aggressive
> -O2 = Speed
> -O3 = Speed+Aggressive
> -Os = Space
> -Oz = Space+Aggressive
> 
> Then passes only need to know which flags are set...

I see what you're driving at although I'd quibble about two things.
- "Debug" is kind of overloaded, maybe "Simple" would express the right
semantic without being so ambiguous (avoid the -g thing!).
- I wonder whether Simple/Speed/Space are better modeled as a single
three-way setting and not as flags.  Is it sensible to have more than 
one of those three on at the same time?  I wouldn't think so...
--paulr

> 
> In our specific case, not running SimplifyCFG and friends would only
> need to know "if (OptLevel.isSpeed()) simplify();". At least the code
> would make more sense to the reader...
> 
> cheers,
> --renato