llvm dev - May 2013 - [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 
heavily used in our field).  Obviously we don't want to significantly 
diverge from the mainline so it would be great to work with the community 
to implement this in such a way that it could be incorporated into the 
mainline and be beneficial to all of the other users too :-).

Andrea Di Biagio
SN Systems - Sony Computer Entertainment Group

**********************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify postmaster at scee.net
This footnote also confirms that this email message has been checked for 
all known viruses.
Sony Computer Entertainment Europe Limited
Registered Office: 10 Great Marlborough Street, London W1F 7LP, United 
Kingdom
Registered in England: 3277793
**********************************************************************

P Please consider the environment before printing this e-mail

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 least (all of the other
> compilers they use already support some form of this feature so it is very
> heavily used in our field).  Obviously we don't want to significantly
> diverge from the mainline so it would be great to work with the community
> to implement this in such a way that it could be incorporated into the
> mainline and be beneficial to all of the other users too :-).
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.

If we do need to enabled/disable passes run in each function, I would
suggest starting by proposing which attributes should be added to the
language reference.

Cheers,
Rafael

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 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
> > heavily used in our field).  Obviously we don't want to
significantly
> > diverge from the mainline so it would be great to work with the
community
> > to implement this in such a way that it could be incorporated into the
> > mainline and be beneficial to all of the other users too :-).
>
> 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.
>
> If we do need to enabled/disable passes run in each function, I would
> suggest starting by proposing which attributes should be added to the
> language reference.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130529/d20cd431/attachment.html>