Re: Documentation and behaviour of the "optimize" attribute

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Richard Guenther" <richard.guenther@gmail.com> writes:
> On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Hi,
>>
>> Sorry in advance if this going over old ground.  And if not, sorry
>> for the somewhat negative message ;), but ...  I think the current
>> documentation and/or behaviour of the "optimize" attribute are a little
>> confusing.
>>
>> The current behaviour is that, if __attribute__((optimize(...))) does
>> not specify an optimisation level (-Ox), we act as though the prevailing
>> -Ox level had been restated.  So:
>>
>>  __attribute__((optimize("no-gcse")))
>>
>> behaves like:
>>
>>  __attribute__((optimize("Ox", "no-gcse")))
>>
>> where Ox is the current optimisation level.  This means that if you
>> compile:
>>
>>  void bar (int);
>>  void __attribute__((optimize("no-gcse"))) f1 (void)
>>  {
>>    bar (1);
>>    bar (2);
>>  }
>>  void f2 (void)
>>  {
>>    bar (1);
>>    bar (2);
>>  }
>>
>> with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
>>
>>  __attribute__((optimize("O2", "no-gcse")))
>>
>> and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
>> So f1 will be compiled without a frame pointer but f2 will be compiled
>> with one.
>>
>> Is this really what we want?  If so, I think it's subtle enough to be
>> worth documenting.  It certainly isn't what I was expecting after
>> reading the current documentation.
>
> IMHO this is a bug.  And IMHO this optimize attribute went way over what was
> reasonable to implement as a start - leading to all of these
> interesting problems.

OK, thanks, I filed it as 38716.  (IMO, this is a different bug
from the one that HJ mentioned, which FWIW I'd seen before the
original post.)

Also, I notice the hash function for the optimisation state is:

  /* assume most opt flags are just 0/1, some are 2-3, and a few might be
     something else.  */
  for (i = 0; i < len; i++)
    if (p[i])
      hash = (hash << 4) ^ ((i << 2) | p[i]);

This looks rather weak.  Many flag_* variables are set when
optimisation is enabled, so most of them will get shifted out
and contribute nothing to the hash value.

Richard