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 sure if anyone would want this in practice. On Thu, Nov 28, 2013 at 5:41 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 28 November 2013 13:31, David Tweed <david.tweed at gmail.com> wrote: >> Indeed, a most of the bugs which >> really need a debugger are manifest in big applications where even a >> non-debug build can be very "not simple".) > > My example was a very crude example of simplicity. But the more > complex your application is, the simpler you want the compiler to be > for a debug session. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 __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). 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. cheers, --renato
> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Evgeniy Stepanov > Sent: Sunday, December 01, 2013 2:45 AM > To: Renato Golin > Cc: LLVM Developers Mailing List > Subject: Re: [LLVMdev] Disabling certain optimizations at -O1? > > 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.Two of the three LLVM patches to implement OptimizeNone are in trunk, the third is pending review. Once all of the LLVM patches are in, I will commit the Clang patch to map __attribute__((optnone)) to the OptimizeNone IR attribute.> 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 sure if anyone would want > this in practice.We at least want LTO with some marked OptimizeNone. Converting the optimization levels to per-function attributes is a different debate. --paulr> > > On Thu, Nov 28, 2013 at 5:41 PM, Renato Golin <renato.golin at linaro.org> > wrote: > > On 28 November 2013 13:31, David Tweed <david.tweed at gmail.com> wrote: > >> Indeed, a most of the bugs which > >> really need a debugger are manifest in big applications where even a > >> non-debug build can be very "not simple".) > > > > My example was a very crude example of simplicity. But the more > > complex your application is, the simpler you want the compiler to be > > for a debug session. > > > > cheers, > > --renato > > _______________________________________________ > > 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
> -----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