[Bug lto/53777] [lto] lto does not propagate optimization flags from command lines given at "compilation time"

[vincenzo.innocente at cern dot ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777

--- Comment #4 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2012-06-28 12:10:44 UTC ---
On 28 Jun, 2012, at 11:44 AM, rguenth at gcc dot gnu.org wrote:

> 
> A very convenient way of "optimize more aggressively some
> computational-intensive code segments" is to use profile-feedback ;)
> 
Indeed, and I'm very pleased that gcc (since 4.6) is able to pgo our
million-lines code!
the use of Ofast is to relax IEEE754 conformance only in specific routines,
mainly to allow "more" vectorization.

>> I suspect that the only safe way is to to segregate the code requested to be
>> compiled with different options, for sure if the option is "lower". Most
>> probably this is not what other users expects.
> 
> So eventually you want to simply not compile the -Os code with -flto so
> that it won't participate in link-time optimization (with using the linker
> plugin you can still get most of the effect of whole-program assumptions).
this is what I'm doing now, as you may have guessed from PR53780...
> Or if you have several -Os sources, do a partial -flto link with -Os and
> link that object in the link-time optimization with -O2.
I've no experience with -Wl,-r (or -Ur?) will try.
> 
> As what the user expects that is not really clear ;)  A quite extreme
> way would be to simply assert that flags on all compiles and the link
> are the same and otherwise give up (or warn).  Another idea was that
> if at link-time no compile options are specified (might be quite common,
> but at least people added -flto somehow) then use the options from
> compile-time (but which, if they differed?).  
Historically we always propagated compiler flags at the linker step.
For sure with lto the meaning of flags at compile vs link time is quite
confusing.
> Another idea was to tag
> the cgraph with the compile options used and adjust the partitioning
> done for the LTRANS stage to be able to have consistent options (that
> might differ between LTRANS units) for all functions inside one LTRANS unit.
This is close to what I would expect to happen.
> For all of the different-flags-at-compile-time issues the issue remains
> what the flags used at link-time mean?  Do they override or amend flags?
I would suggest to issue warning or at least to clarify your choices
> (We specifically thought of libraries shipped with LTO bytecode
> compiled at -O0 -g to be used for both debugging and optimized compile
> by means of optimizing only at link-time)
> 
Clever, a bit confusing though.
I've moved to -fno-fat-lto-objects also to make sure that the plugin is used.