Re: [Announcement] Creating lightweight IPO branch

[Richard Guenther <richard dot guenther at gmail dot com>]

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?

Thanks,
Richard.