On Tue, May 5, 2009 at 7:56 PM, Xinliang David Li <davi...@google.com> wrote: > On Tue, May 5, 2009 at 2:47 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Tue, May 5, 2009 at 7:00 AM, Xinliang David Li <davi...@google.com> wrote: >>> Hi, I am going to create a gcc branch for the functionality of >>> lightweight IPO. The description of the project and current status can >>> be found in http://gcc.gnu.org/wiki/LightweightIpo. Some highlights: >>> >>> 1) If you already use FDO in your build, you also get IPO almost for free; >>> 2) It is an IPO solution practical to very large real world C++ >>> applications; >>> 3) Performance potential is very large (though I've seen case >>> increased compiler freedom can lead to performance degradation due to >>> over-optimization (inliner, unroller etc) -- but this is a different >>> matter). >>> >>> If the idea is generally accepted, I will prepare a series of patches >>> and submit them to gcc trunk. >> >> I was hoping that with LTO we can get rid of -combine, as its type/decl >> merging is fragile in many cases. Does this somehow conflict with >> LIPO? > > LIPO does not depend on existing type/decl merging functionality -- > though it does leverage the parser driver code -- mainly extending the > filescope push/pop thingy, so mostly there is no conflict. > > From what I understand is that you are merging TUs in the >> frontend (like -combine) - did you consider merging TUs with the >> LTO infrastructure, but in memory? > > In LIPO, TU merging does not happen in frontend (the document may > sound a little confusing) -- the modules are parsed independently and > merged/linked after parsing. Diego and I talked about the possibilty > of using LTO to do this -- but that requires significant driver > change.
I see - so the modules are parsed and transformed to gimple (or generic?) and then merged. But then LTO and LIPO (could) share decl and type merging code at least, no? Thanks, Richard.
