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

vincenzo.innocente at cern dot ch gcc-bugzilla@gcc.gnu.org
Thu Jun 28 05:08:00 GMT 2012


--- Comment #2 from vincenzo Innocente <vincenzo.innocente at cern dot ch> 2012-06-28 05:07:57 UTC ---
I fully agree that combining code sections to be optimized differently is not
well defined in particular when optimization works looking at a broader scope.
In principle one can imagine that an optimization-flag change should be
considered as an optimization barrier, but that clearly defeats the very
purpose of optimization itself and may lead to code that is less performant
that if compiled with the lower of all options...

Most probably we should go back and understand WHY users choose different
optimization level for different code sections.

In some cases is to workaround a compiler or coding problem

In our specific case the code to be compiled with -Os is "machine generated"
and contains mostly streamers not very sensitive to aggressive optimization
(vectorization helps in some, at best) : we judged that a smaller code (much
smaller actually!) and faster compilation was more effective.
It is packaged in the same library with the class they have to stream for
convenience and dependency management.
In reality I noticed that with lto the compilation time is fully dominated by
those files, so it is surely not "fast-developement" friendly. I suspect that
the final solution will be to segregate them into their own library.

I also experimented with trying to optimize more aggressively some
computational-intensive code segments.
In principle it could make sense, in practice I understand that as soon as
inter-procedural optimization kicks-in having code fragments with Ofast and
other with O2 can make little sense even from a pure numerical point of view:
think of an expression found in both sections that can be factorized out.

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.

More information about the Gcc-bugs mailing list