[LLVMdev] Disabling certain optimizations at -O1?

[Renato Golin]

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

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


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


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

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