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

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

> 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.
I have a similar usage case: I work on code that tends to show up optimiser
bugs, possibly because it is very thoroughly tested. Optimization control
pragmas are invaluable for locating optimizer bugs in a particular function;
the lack of them is one of the reasons why my GCC and Clang builds don't
have
optimization turned up so high as on some other compilers.

--
John Dallman
-----------------
Siemens Industry Software Limited is a limited company registered in England and
Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey,
GU16 8QD.

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 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
that it can be automated -- you should not expect doing this via
source modification
2) Improve debuggability of optimized code. GCC has -Og option that
can be used to generate well optimized code with good debuggability.
3) there is a much bigger issue if the customer needs to resort to
this pragmas frequently to hide optimizer bugs.



David


On Wed, Jun 12, 2013 at 8:11 AM, Dallman, John <john.dallman at
siemens.com> wrote:
>> 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.
>
> I have a similar usage case: I work on code that tends to show up optimiser
> bugs, possibly because it is very thoroughly tested. Optimization control
> pragmas are invaluable for locating optimizer bugs in a particular
function;
> the lack of them is one of the reasons why my GCC and Clang builds
don't have
> optimization turned up so high as on some other compilers.
>
> --
> John Dallman
> -----------------
> Siemens Industry Software Limited is a limited company registered in
England and Wales.
> Registered number: 3476850.
> Registered office: Faraday House, Sir William Siemens Square, Frimley,
Surrey, GU16 8QD.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev