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

Hi Jonathan,
> From: Jonathan Sauer <jonathan.sauer at gmx.de>
> Have you looked at "Noise", presented at this year's European
LLVM
Conference?
> 
> | Noise is a language extension that allows a programmer to create 
> custom optimization
> | strategies and apply them to specific code segments. This enables 
> fine-grained control
> | over the optimizations applied by the compiler to conveniently 
> tune code without
> | actually rewriting it.
> <http://llvm.org/devmtg/2013-04/#poster6>
> 
> This seems to go into the same direction as your proposal. It's not 
> yet open source,
> but it's planned:
<http://www.cdl.uni-saarland.de/projects/noise/>
Thanks for the feedback.
During the poster session I had a quick chat with Ralf Karrenberg who gave 
a lightning talk on project Noise.

In my understanding, their approach consists in running a sequence of 
extra optimization passes on 
functions and/or blocks of code (either generic compound statements or 
loop statements) guarded by the NOISE keyword.
Those extra passes are run on the IR produced by Clang and before the 
optimizer takes place.

Their approach does not allow for example to selectively disable passes or 
in general to override optimization options for specific functions. 

Also, the sequence of extra passes is always run in order based on the 
sequence specified by the user through the NOISE keyword.
No changes are required for the optimizer which still works as before:
 1) pass managers are still populated based on the global optimization 
level;
 2) there is no way to dynamically select passes to run based on the 
per-function optimization level.

The only use case (partially) in common between my proposal and their 
approach seems to be the case where the user tries to run extra 
optimizations on specific functions.


**********************************************************************
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

Hi Andrea,

please excuse the very delayed response, this thread somehow got out of 
my sight before I found the time to respond.

As Jonathan and you have mentioned already, "Noise" is indeed going
into
the same direction. Let me comment on a few of your observations:

On 5/7/13 7:02 PM, Andrea_DiBiagio at sn.scee.net wrote:
> In my understanding, their approach consists in running a sequence of
> extra optimization passes on
> functions and/or blocks of code (either generic compound statements or
> loop statements) guarded by the NOISE keyword.
> Those extra passes are run on the IR produced by Clang and before the
> optimizer takes place.
>
> Their approach does not allow for example to selectively disable passes or
> in general to override optimization options for specific functions.
This is not entirely true.
We actually *do* override the general optimization options set via 
command line for that specified piece of code. The intent of the noise 
attribute is exactly to give the programmer *full* control over what 
optimizations are applied to a given code segment (a function, loop, or 
compound statement). This includes the fact that using an empty noise 
attribute results in no optimization being applied.
The only thing we currently do not support is something along the lines 
of "please do -O3 but exclude passes X, Y, and Z". However, this is
not
a conceptual shortcoming but simply not implemented yet.
> Also, the sequence of extra passes is always run in order based on the
> sequence specified by the user through the NOISE keyword.
> No changes are required for the optimizer which still works as before:
>   1) pass managers are still populated based on the global optimization
> level;
To further clarify what I stated above: This is only true for all code 
*except* the parts marked with noise attributes.
>   2) there is no way to dynamically select passes to run based on the
> per-function optimization level.
I don't understand what "dynamically" means here.
> The only use case (partially) in common between my proposal and their
> approach seems to be the case where the user tries to run extra
> optimizations on specific functions.
To sum it up, frankly, I don't think so ;).

Take a look at the examples on our webpage if you like:
http://www.cdl.uni-saarland.de/projects/noise

All of those only show what happens to the attributed functions. The 
rest of the program is compiled as it would have been with an unmodified 
Clang (e.g. all code that is not marked is optimized with -O3 if that is 
supplied via command line).

Best,
Ralf