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

Xinliang David Li xinliangli at gmail.com
Thu Jun 13 15:24:35 PDT 2013


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



More information about the cfe-dev mailing list