Forgot to copy the reply to the mailing list. David
---------- Forwarded message ---------- From: Xinliang David Li <davi...@google.com> Date: Wed, May 6, 2009 at 10:08 AM Subject: Re: [Announcement] Creating lightweight IPO branch To: Richard Guenther <richard.guent...@gmail.com> On Wed, May 6, 2009 at 2:00 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > 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? LIPO take a approach that involves very little 'physical merging'. Function call target fixup is only done on callgraph, and global variable reference fix up is done on demand (lazily) when inlining happens. LIPO does type merging based on qualified names (not structural equivalence) -- and there are no type reference fixups in actual IL. The type merging is used for type based aliasing and allow conservative merging (two different types with the same name --- this violates ODR and can be warned -- but such programs do exist) -- but does not allow false negative (which can easily happen if structrual equalivalence check fails). The design goal of LIPO is simplicity and least intrusiveness. By the way, I saw a recent email asking about --combine support for C++. In fact LIPO's mechanism can be easily adapted to support that (and also changing C's implementation to make it more source tolerant) -- but I doubt how useful -combine will be for C++ programs. Thanks, David > > Thanks, > Richard. >
