This is the mail archive of the 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]

Re: GCC-4.5.0 comparison with previous releases and LLVM-2.7 on SPEC2000 for x86/x86_64

On Thu, Apr 29, 2010 at 4:03 PM, Jan Hubicka <> wrote:
>> 2010/4/30 Jan Hubicka <>:
>> >> Thanks for the suggestion. Raksit currently is busy with merging trunk
>> >> changes back to lw-ipo branch which can be a daunting task. After that
>> >> this can be done. ?(Our internal release is based on 4.4).
>> >
>> > I must say that LIPO is something I always intend to look into but didn't
>> > seriously find time for that yet (well, hoping that submitting the thesis will
>> > make this easier).
>> > What are the LIPO's features that are missing in -flto -fprofile-use?
>> LIPO is a completely different approach, basically independent of LTO.
>> There is a good explanation of it on the wiki, see
> Yep, I read that page (and saw some of implementation too). ?Just was not able
> to follow the precise feature set of LIPO (i.e. if it gets better SPEC results
> than LTO+FDO then why)

In theory, LIPO should not generate better results than LTO+FDO. What
makes LIPO attractive is that it allows distributed build from the
beginning. Its integration with large distributed build system is also
easy.  Another point is that LIPO can be decoupled from FDO as well.
The reason is that cross module call clusters do not change that much
and can be determined statically or determined once using sample
profiling information. The grouping info can then be used for regular
O2 builds. This will remove the need for people to move functions into
header files which tend to penalize compile time unnecessarily.

If there is performance difference, the following unique things in
LIPO may contribute to it ( I have not validate them)

1) LIPO supports tracking indirect call targets across modules. This
is not feasible for plain FDO as there will be cgraph pid conflicts.
LIPO uses unique function id == (module_id << 32) + func_def_no, which
makes it possible.
2) comdat function resolution -- since LIPO uses aux module functions
for inlining purpose only, it has the freedom to choose which copy to
use. The current scheme chooses copy in current module with priority
for better profile data context sensitivity (see below)
3) in profile-gen phase, allow more inlining for comdat functions (in
einline2 and ipa-inline) -- this will cause profile data to be tracked
with module sensitivity (note that counters are not in comdat group)



> Honza
>> Ciao!
>> Steven

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