Optimize attribute and inlining

[David Brown]

On 26/07/2012 14:04, Richard Guenther wrote:
> On Thu, Jul 26, 2012 at 1:21 PM, David Brown <david@westcontrol.com> wrote:
>> On 26/07/2012 11:12, Richard Guenther wrote:
>>>
>>> On Wed, Jul 25, 2012 at 8:25 PM, David Brown <david.brown@hesbynett.no>
>>> wrote:
>>>>
>>>> On 25/07/12 17:30, Richard Guenther wrote:
>>>>>
>>>>>
>>>>> On Wed, Jul 25, 2012 at 4:07 PM, Selvaraj, Senthil_Kumar
>>>>> <Senthil_Kumar.Selvaraj@atmel.com>  wrote:
>>>>>>
>>>>>>
>>>>>> Declaring a function with __attribute__((optimize("O0")) turns off
>>>>>> inlining for the translation unit (atleast) containing the function
>>>>>> (see output at the end). Is this expected behavior?
>>>>>
>>>>>
>>>>>
>>>>> Not really.  The optimize attribute processing should only affect
>>>>> flags it saves.  -f[no-]inline is not meaningful per function and we
>>>>> have the noinline attribute for more proper handling.
>>>>>
>>>>> That said, I consider the optimize attribute code seriously broken
>>>>> and unmaintained (but sometimes useful for debugging - and only
>>>>> that).
>>>>>
>>>>
>>>> That's a pity.  It's understandable - changing optimisation levels on
>>>> different functions is always going to be problematic, since
>>>> inter-function
>>>> optimisations (like inlining) are going to be difficult to define.  But
>>>> sometimes it could be nice to use specific optimisations in specific
>>>> places,
>>>> such as loop unrolling in a critical function while other code is to be
>>>> optimised for code size.  Does "#pragma Gcc optimize" work more reliably?
>>>
>>>
>>> No, it uses the same mechanism internally.
>>>
>>> Richard.
>>>
>>
>> Is it reliable to use "#pragma Gcc optimize" options at the start of the
>> file, as an alternative to specifying them in the command line?  For
>> example, a Makefile might specify "-Os" as standard options for all c files,
>> but one particular file might have "#pragma Gcc optimize 3" at the start.
>> If the line is at the start of the file, before any #includes or code, then
>> there would be no mixing of optimisation levels.
>
> Behavior will not be the same for
>
> gcc -include foo.h x.c
>
> when you change x.c in the proposed way compared to
>
> gcc -include foo.h x.c -O3

Fair enough - but will "gcc x.c -Os" with "#pragma Gcc optimize 3" as 
the first line of "x.c" do the same thing as "gcc x.c -O3" ?

I realise that we can't get everything here.  C in general, and gcc in 
particular, is extremely flexible - there are always going to be ways to 
cause trouble.

But while it is always best to write source code that works correctly 
regardless of the optimisation levels, occasionally there is code with 
special requirements.  It might be code that should be optimised 
particularly aggressively, or it might be code that should not be 
optimised, or have other options (such as older code that breaks strict 
aliasing rules).  I think such requirements are best put in the C file 
(as pragmas or attributes) rather than in a Makefile - it binds them 
tighter to the code in question.

If the pragmas work as long as they come before any other code, then 
that gives them a useful, though limited, purpose.

>
>> And if these options are so broken, should they be marked as such in the
>> manual?
>
> Probably yes.

Or they could be fixed :-)

Could the pragmas be changed (or replaced) with ones explicitly designed 
to override command-line options, regardless of where they appear in the 
order in the file?  Of course, you are still going to get conflicts when 
someone specifies more than one c file on the command line, each of 
which contains such overrides - I think the reasonable thing to do this 
is just exit with an error message.

>
>> Thanks for your time here.
>>
>> David
>>