[LLVMdev] Disabling certain optimizations at -O1?

Robinson, Paul Paul_Robinson at playstation.sony.com
Sun Dec 1 16:59:08 PST 2013


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Renato Golin
> Sent: Sunday, December 01, 2013 4:39 AM
> To: Evgeniy Stepanov
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Disabling certain optimizations at -O1?
> 
> 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.

You are now getting into behavior affecting the pass manager which
is a different debate.

> 
> 
> > 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 __attribute__(optimize(loop-vectorize)) or #pragma GCC
> optimize loop-vectorize, but on a loop/block level. (Note to self, I
> could do that on a function level, too).
> 
> For this change, I'll have to always add the vectorizer pass, but with
> a flag on constructor specifying if I want it to always run, or only
> with a pragma. The same thing can be done with the #pragma GCC
> optimize (which we should support as is, but call #pragma optimize and
> ask GCC to support both).

No, because then we're saying Clang and GCC optimization levels track
each other.  I haven't seen anybody say that degree of consistency
between GCC and Clang is a wonderful plan.

> 
> Same thing with optimization levels (#pragma optimize 3), we can embed
> the knowledge of the flags and optimization level, so then when we
> pass them to the passes, we already know what we want to run without
> having to change in many places.
> 
> In the end, populateModulePassManager() should be about building the
> flags table and (almost) unconditionally adding all passes with the
> respective flags.

You need to engage Chandler about his long-term Pass Manager plan
about that.  This is a rather larger topic than we started with on
this thread.
--paulr

> 
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev






More information about the llvm-dev mailing list