http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-28 09:44:40 UTC --- (In reply to comment #2) > 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 Right. In that case I'd say the specific object should better not participate in the LTO link (thus do not use -flto at .c -> .o compile time for that object). > 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. A very convenient way of "optimize more aggressively some computational-intensive code segments" is to use profile-feedback ;) > 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). 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. 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?). 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. 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? (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)
