http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
--- 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.
