llvm dev - May 2013 - [LLVMdev] [cfe-dev] [PROPOSAL] per-function optimization level control

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>

> 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 the function's attributes?

Cheers,
Rafael

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 of making sure that 
some functions are never optimized is the most critical one.  The major 
use-case for this is for ease of debugging optimized builds.  Generally, 
the type of programs that our users are writing run so slowly in 
unoptimized builds that they are essentially unusable for 
testing/debugging purposes.  Unfortunately in fully optimized builds, as 
we all know, the debugging experience is not always entirely pleasant. Our 
users generally build against multiple targets each with their own 
compiler and have adopted the typical workflow of marking functions and 
ranges of functions that need closer inspection in the debugger with a 
pragma to prevent the optimizer from coming along and hurting the 
debuggability of them whilst still running with everything else fully 
optimized and at a usable speed. 

Rafael Espíndola <rafael.espindola at gmail.com> wrote on 29/05/2013 
16:04:47:
> > 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 the function's attributes?
Yes, Chandler's proposal goes on the same direction as our proposal. In 
fact the declared goals was 
"to allow a specific function to have its optimization level overridden 
from the command line based level".
Our proposal tries also to focus more on how function attributes could be 
used to guide pass managers in the process of selecting which passes to 
run etc.

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

The pass manager, as it is designed now, doesn't have the capability to
dynamically change pass configurations. Until that's fixed, the only way to
do this would be for clang to build multiple pass managers. That would open a
can of worm though.

Evan

Sent from my iPad

On May 29, 2013, at 8:04 AM, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
>> 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 the function's attributes?
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev