Andrew Pinski wrote: > On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > >> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote: >> >> >>> If the version of GCC being used isn't compatible with the version of the IL >>> in the object file, we can just fall back on the final code. >>> >> Fair enough. But this could be provided via a flag to optionally emit >> final code. The more common scenario is likely to be hermetic builds >> that use the same compiler throughout. Duplicating code generation >> for *every* build seems too wasteful to make it the compiler's default >> behaviour. >> > > The idea was that people did not have to change their makefiles. If > some static library provided by vendor 1 does not include the real > machine code, then the build just fails. So having the machine code > by default is still seems like the correct idea to go forward and > provided a flag to turn off it if really needed (though I think it is > bad to have two different modes in this case). > > Thanks, > Andrew Pinski > Sorry to have missed most of this thread today. i was at a meeting in the city all day.
Andrew is correct that the reason for putting both lto and final code in the same file was to do the least damage to peoples build tools. A change from each invocation of gcc produce two files instead of one will severely break many people's build environments. Mark and I were very concerned about how widely used LTO would be, if trying it cost more than adding -flto in several places. As far as the support of non elf compilers, the idea was to minimize and modularize the actual dependence of elf as much as possible and then to let anyone who was still non elf fill in the pieces. At the present time, all of the uses of elf go thru indirect calls so in theory this will be easy. However, in practice this is likely to be harder. For instance the current lto implementation assumes that there can be a lot of different sections, but for instance the aix format does not allow this.
