This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fwd: [Announcement] Creating lightweight IPO branch


Forgot to copy the reply to the mailing list.

David


---------- Forwarded message ----------
From: Xinliang David Li <davidxl@google.com>
Date: Wed, May 6, 2009 at 10:08 AM
Subject: Re: [Announcement] Creating lightweight IPO branch
To: Richard Guenther <richard.guenther@gmail.com>


On Wed, May 6, 2009 at 2:00 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, May 5, 2009 at 7:56 PM, Xinliang David Li <davidxl@google.com> wrote:
>> On Tue, May 5, 2009 at 2:47 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Tue, May 5, 2009 at 7:00 AM, Xinliang David Li <davidxl@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.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]