Diego, thanks for brining LIPO into discussion.
There is a common misunderstanding of LIPO. It is not about
partitioning, but about extending single module compilation scope to
multiple/cross module. For instance for a build with a.c, b.c, c.c,
and d.c, LIPO does not partition them into
{a.c b.c}
{c.c d.c}
but extend for instance a.c to include c.c (as auxilary module), so
there will be still 4 independent compilations instead of 2:
{a.c, c.c}
b.c
c.c
d.c
There will be a LIPO presentation in this year's CGO. LIPO has been
used successfully for very large applications. Another news is that
there is an effort to do LIPO with sampled FDO -- that means you don't
have to have the instrumentation step in order to use LIPO.
I want to use this opportunity to emphasize a couple of points:
1) people use IPO because they care about performance. However IPO
won't be that effective without FDO except for really small toy
programs.
2) on contrary to what many thinks, FDO is used in real life and the
process is not as horrible as people think
3) LIPO adds IPO capability into FDO almost seamlessly which makes it
really attractive and easy to adopt (esp when FDO is already used).
Thanks,
David
On Thu, Apr 8, 2010 at 11:37 AM, Diego Novillo <dnovi...@google.com> wrote:
> On 4/8/10 14:34 , Jan Hubicka wrote:
>>> On 4/8/10 14:30 , Jan Hubicka wrote:
>>>>>> On 4/8/10 14:10 , Jan Hubicka wrote:
>>>>>>
>>>>>>> So I think tying WHOPR and profile feedback too close together is a
>>>>>>> mistake.
>>>>>>
>>>>>> Sorry, I didn't mean that. My intent is to make whopr/lto use profiling
>>>>>> information if it is available. Much like we do with other optimization
>>>>>> decisions. They transparently become more precise in the presence of
>>>>>> profiling information.
>>>>>
>>>>> Both LTO and WHOPR now works with profiling pretty well (and I've switched
>>>> ^^^^^ too much of market speach. WHOPR is not working well,
>>>> profile feedback or not ;)
>>>
>>> Ah! I was going to say :)
>>>
>>> For WHOPR, the partitioning should be driven by profile info (if
>>> available). First, it should Just Work, of course.
>>
>> Well, since we should be able to stream out the result of IPA propagation
>> across whole program, the particular partitioning decision should not be that
>> important (i.e. affecting the propagation in late compilation and possibly
>> some
>> simple IPA passes we might do before but don't at the moment).
>>
>> But yes, we should be able to get hot part of program into single closed
>> partition or something like that to get some extra score.
>
> Right. That's (in its most basic form) what LIPO does with the grouping
> model. David, what else does LIPO use the profiling information for?
>
>
> Diego.
>
