Re: Documentation and behaviour of the "optimize" attribute

["Richard Guenther" <richard dot guenther at gmail dot com>]

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.

Richard.

> Richard
>