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. > > On the whole LIPO sounds indeed very interesting. Thanks, David > > Thanks, > Richard. >
