similar to: [LLVMdev] [cfe-dev] [PROPOSAL] per-function optimization level control

Hi, I just wanted to bump this discussion in case anyone had any more comments to make. We're in a bit of a bind here as we've now had requests for this feature from 10 separate customers, so we're going to be required to implement this feature somehow in our private branch at least (all of the other compilers they use already support some form of this feature so it is very

On Fri, Jun 14, 2013 at 4:06 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > Hi David, > >> Regarding Andrea's proposal -- the new #pragma can be useful (in rare >> cases when there is a compiler bug), the intended use cases are >> questionable: >> 1) it should not be used as a mechanism to triage compiler bugs -- the >> compiler backend should have

Hi David, > Regarding Andrea's proposal -- the new #pragma can be useful (in rare > cases when there is a compiler bug), the intended use cases are > questionable: > 1) it should not be used as a mechanism to triage compiler bugs -- the > compiler backend should have mechanism to allow any pass to be > disabled for any (range of) function(s) via command line options so >

On 29 May 2013 09:28, <Andrea_DiBiagio at sn.scee.net> wrote: > Hi, > > I just wanted to bump this discussion in case anyone had any more comments > to make. > > We're in a bit of a bind here as we've now had requests for this feature > from 10 separate customers, so we're going to be required to implement > this feature somehow in our private branch at

On Wed, Apr 24, 2013 at 6:00 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > Hello, > > We've had a high priority feature request from a number of our customers > to > provide per-function optimization in our Clang/LLVM compiler. > I would be interested in working with the community to implement this. > The idea is to allow the optimization level to be overridden >

GCC's optimize attribute should work fine (at least with trunk): __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) { ... } will turn on -O3 for 'foo', but disable PRE pass for it. If you see any problems there, you should file a bug. Regarding Andrea's proposal -- the new #pragma can be useful (in rare cases when there is a compiler bug), the

On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li <xinliangli at gmail.com> wrote: > On Fri, Jun 14, 2013 at 4:06 AM, <Andrea_DiBiagio at sn.scee.net> wrote: >> Hi David, >> >>> Regarding Andrea's proposal -- the new #pragma can be useful (in rare >>> cases when there is a compiler bug), the intended use cases are >>> questionable:

On Fri, Jun 14, 2013 at 11:36 AM, Eric Christopher <echristo at gmail.com> wrote: > On Fri, Jun 14, 2013 at 10:36 AM, Xinliang David Li > <xinliangli at gmail.com> wrote: >> On Fri, Jun 14, 2013 at 4:06 AM, <Andrea_DiBiagio at sn.scee.net> wrote: >>> Hi David, >>> >>>> Regarding Andrea's proposal -- the new #pragma can be useful (in

Especially since we have support for per function code gen attributes now. -eric On Wed, Apr 24, 2013 at 3:50 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Wed, Apr 24, 2013 at 6:00 AM, <Andrea_DiBiagio at sn.scee.net> wrote: >> >> Hello, >> >> We've had a high priority feature request from a number of our customers >> to >>

Hello, We've had a high priority feature request from a number of our customers to provide per-function optimization in our Clang/LLVM compiler. I would be interested in working with the community to implement this. The idea is to allow the optimization level to be overridden for specific functions. The rest of this proposal is organized as follows: - Section 1. describes this new feature

On Wed, May 29, 2013 at 10:17 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 29 May 2013 09:28, <Andrea_DiBiagio at sn.scee.net> wrote: > > Hi, > > > > I just wanted to bump this discussion in case anyone had any more > comments > > to make. > > > > We're in a bit of a bind here as we've now had requests for this

Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that throughout the optimization phases, there is an implied assumption that all functions are similarly optimized. An example would be under certain optimization flag, compiler changes calling convention of static functions. - Fariborz On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote: >

In reply to the question about what would be the common use case: > What is the common use case? Making sure some funtion is always > optimized or making sure it never optimized? If the second one, I > wonder if marking it cold would be a good enough approximation. Although both cases would be nice and our users have expressed some interest in both, the critical one is the second case

Dropping opt level should not lead to ABI changes. Otherwise you won't be able to mix-match O2 and O0 objects either. David On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com> wrote: > Wouldn’t implementing this proposal be a red herring? By this I mean, it is > possible that > throughout the optimization phases, there is an implied assumption that all >

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at gmail.com> wrote: > Dropping opt level should not lead to ABI changes. Otherwise you won't > be able to mix-match O2 and O0 objects either. I was referring to “static functions”. Not that it happens, but something to consider. - Fariborz > > David > > On Mon, Jun 17, 2013 at 10:59 AM, jahanian

Andrea_DiBiagio at sn.scee.net wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of the new attribute. > > Here are the

> Wasn't this already proposed? > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058112.html > > LLVM already has optsize. Maybe it's just a matter of hooking up gcc's > attr(optimize) to it in clang, as a first approximation. Looks like it, yes! Chandler, what were you thoughts on the pass manager? Should it select the set of passes for a function based on

On Thu, Jul 18, 2013 at 8:23 AM, <Andrea_DiBiagio at sn.scee.net> wrote: > So.. > I have investigated more on how a new function attribute to disable > optimization on a per-function basis could be implemented. > At the current state, with the lack of specific support from the pass > managers I found two big problems when trying to implement a prototype > implementation of

Hi, On 13.06.2013 20:15, Xinliang David Li wrote: > GCC's optimize attribute should work fine (at least with trunk): > > __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) > { > ... > } > > will turn on -O3 for 'foo', but disable PRE pass for it. Indeed, the optimize attribute should do the job if you require optimization

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and