On Thu, Apr 29, 2010 at 4:03 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >> 2010/4/30 Jan Hubicka <hubi...@ucw.cz>: >> >> 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 >> http://gcc.gnu.org/wiki/LightweightIpo. > > 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) Thanks, David > Honza >> >> Ciao! >> Steven >
