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

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

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 control on function level only.

If you need finer-grained control mechanisms, you need to resort to a 
pragma or attributes (or whatever kind of annotation) approach.
For instance, noise allows you to annotate loops or compound statements.
> 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.
I agree, these are indeed questionable.
However, there is a very important use case that I would call 
"performance tuning of critical code segments".

Cheers,
Ralf
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Thu, Jun 13, 2013 at 1:40 PM, Ralf Karrenberg <Chareos at gmx.de>
wrote:
> 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
> control on function level only.
>
> If you need finer-grained control mechanisms, you need to resort to a
pragma
> or attributes (or whatever kind of annotation) approach.
> For instance, noise allows you to annotate loops or compound statements.
>

yes -- I like the fine grain control capability provided by Noise --
it will be a very useful tool for compiler engineers to find
opportunities and tune the default compiler behavior.  Using the
annotations in the source to 'permanently override compiler's
decisions won't be good as it may get stale/invalid overtime or be
invalid for different targets (e.g. unroll decisions).
>
>> 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.
>
>
> I agree, these are indeed questionable.
> However, there is a very important use case that I would call
"performance
> tuning of critical code segments".
yes, and that.

thanks,

David
>
> Cheers,
> Ralf
>
>
>>
>> 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
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>

> 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
That would be just fine; I'm not seeking pragmas specifically, just a
way to control optimisation with finer distinction than a whole file.
> 3) there is a much bigger issue if the customer needs to resort to
> this pragmas frequently to hide optimizer bugs.
I'm not using them to hide optimise bugs, but to help isolate them so
that they can be reported effectively.

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

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
> 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.
Just to clarify, although in our opinion the ability to workaround 
optimization
bugs is a useful side effect of this proposal, we don't consider it the 
main
use case.
That's probably my fault, I should have put more emphasis on the main use 
case:

"The main motivation of our customers is to be able to selectively disable
optimizations when debugging one function in a compilation unit, in the 
case 
where compiling the whole unit at -O0 would make the program run too 
slowly."

In general, it is something that should help improve the debugging 
experience when customers have to debug specific portions of their code 
without sacrificing any of their overall runtime performances.
As a side note, using GCC is not a option for us.

We discussed this proposal with a number of people at the recent Bay Area 
social and agreed to submit a new proposal which should be much simpler 
and smaller in scope to let us achieve our primary use case by adding a 
function attribute (something like: "optnone").
Hopefully I'll post this on the list early next week.

Thanks,
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 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 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.
>
> Just to clarify, although in our opinion the ability to workaround
> optimization
> bugs is a useful side effect of this proposal, we don't consider it the
> main
> use case.
> That's probably my fault, I should have put more emphasis on the main
use
> case:
>
> "The main motivation of our customers is to be able to selectively
disable
> optimizations when debugging one function in a compilation unit, in the
> case
> where compiling the whole unit at -O0 would make the program run too
> slowly."
>
> In general, it is something that should help improve the debugging
> experience when customers have to debug specific portions of their code
> without sacrificing any of their overall runtime performances.
> As a side note, using GCC is not a option for us.
>
To be clear, I am not advocating GCC at all here. Just pointing out
there is room for improvement for DOC so that user does not need to
resort to these workarounds. I know Eric Christopher  is working very
hard to make this happen for LLVM :)

thanks,

David

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