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]

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


On Thu, Nov 18, 2010 at 4:12 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
>> I'll get back to you with our local inlining changes. ?We're looking to move
>> development closer to trunk to reduce this divergence in the future.
>>
>> Our tuning was done primarily on big c++ programs. ?A significant size
>> improvement came from aggressively inlining functions which might be
>> eliminated by the linker (garbage collection of uncalled functions). ?We
>> found that for non-static functions, if all callsites of a function are
>> inlined, the function rarely appears in the final binary (excepting address
>> taken functions). ?Of course, this doesn't necessarily work for libraries
>> which may need all non-static functions to be emitted.
>
> Interesting. Coincidentally I recently added logic for this for comdat
> functions (setting probability to 20%) to deal with problems that a lot of C++
> programs does template instatiations that produce comdat functoins for now good
> reason. ?This indeed helped quite a lot. ?I didn't got so far to set similar
> logic for normal external functions, since current toolchain won't eliminate
> them by default.
>
> Did the posted size numbers include function garbage collection and unification
> that is same for mainline as for google copmiler?

My previous size numbers are wrong --- looks like trunk gcc does
pretty well  in terms of text size. Update numbers will be posted
later.

Yes, all experiments were done with GC, but safe ICF was not turned on.

David


>
> Honza
>


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