RFA: Set default optimization level to -O2 for -flto

[Richard Guenther]

On Fri, Mar 19, 2010 at 2:51 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> Hi -
>
> On Fri, Mar 19, 2010 at 02:44:29PM +0100, Richard Guenther wrote:
>> [...]
>> I don't think this is a good approach.
>
> What would be a better technical measure?  If -flto is intended to be
> an optimization measure, what's the down-side of inferring something
> like -O2 in this case?  The up-side is clear - one less flag to
> propagate into an unusual spot in a makefile.

The down-side is that you have inconsistent behavior of gcc -c -flto
and gcc -flto.  Given that we default to -O0 if no -On is specified
it would be more confusing to magically make -O2 the default if
no -On is specified together with -flto at link time.

If you manage to propagate -flto in your makefile propagating
$CFLAGS as well shouldn't be rocket science anymore.

Now, what would be a better technical measure?  Well - we have
to address the issue of compiling different TUs with different
optimization levels and flags and then being re-optimized at link
time with one set of optimization level and flags.  The current
partly merging of flags has numerous problems and accepting
all weird combinations of compile vs. link flags does have problems
(just search the list of LTO bugzillas).

I didn't yet come up with a good idea how to best merge
TU 1 compiled with -O1 and TU 2 compiled with -O2.  The best
to know is the user, so if he chooses to optimize with -O1 at
link time he gets what he asked for, likewise if he chooses to
optimize with -O2 there.  We could disallow the seemingly
pointless -O0 at link time if at least one TU was built with
optimization, but would you be ok with emitting an error in
that case?  We could also save and merge TU flags as long
as they are completely identical and use them for linking
if there are no flags beside -flto on the link command line
(but how'd you handle compiling with -O2 and
linking with -flto -ffast-math for example?)

So in the end the situation is complex and I don't like to rush
with a "well, maybe using -O2 makes sense" solution because
that doesn't even try to address all the issues but locks us in
(we can't really change what plain -flto does all the time).

>> Instead if you think documentation is unclear at the moment please
>> consider clarifying it.
>
> (Documentation is useful, but intuitive operation that needs no
> documentation is better.)

Well, gcc doesn't optimize by default either, so I think it is already
intuitive.  To me at least.

Richard.