This is the mail archive of the
mailing list for the GCC project.
Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Renato Golin <renato dot golin at linaro dot org>
- Cc: Bingfeng Mei <bmei at broadcom dot com>, Vladimir Makarov <vmakarov at redhat dot com>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, "gcc.gcc.gnu.org" <gcc at gcc dot gnu dot org>
- Date: Tue, 15 Jul 2014 16:43:56 +0200
- Subject: Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM
- Authentication-results: sourceware.org; auth=none
- References: <53A98705 dot 10909 at redhat dot com> <53A98CE2 dot 9080108 at arm dot com> <53A98F0A dot 7000802 at redhat dot com> <53A991D7 dot 6070709 at arm dot com> <53A993F8 dot 7030101 at redhat dot com> <B71DF1153024A14EABB94E39368E44A6042CE185 at SJEXCHMB13 dot corp dot ad dot broadcom dot com> <CAMSE1kdDrF1urKf5yeoou3Y_o2gf8Gk5CTWw4_i3_sCjaA54gg at mail dot gmail dot com>
> On 25 June 2014 10:26, Bingfeng Mei <email@example.com> wrote:
> > Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
> > on GCC? It doesn't seem increasing code size help performance (164.gzip & 197.parser)
> > Is there comparisons for O2? I guess that is more useful for typical
> > mobile/embedded programmers.
> Hi Bingfeng,
> My analysis wasn't as thorough as Vladimir's, but I found that GCC
> wasn't eliminating some large blocks of dead code or inlining as much
> as LLVM was. I haven't dug deeper, though. Some of the differences
I would be defnitely interested in such testcases.. I do not think we should be
just missing DCE oppurtunities. As for inlining, GCC often disables inlining based
on profile (by concluding that given call is cold), but that should not result
in larger code of course.
I also noticed that GCC code size is bigger for both firefox and libreoffice.
There was some extra bloat in 4.9 compared to 4.8.
Martin did some tests with -O2 and various flags, perhaps we could trottle
some of -O2 optimizations.
> were quite big, I'd be surprised if it all can be explained by
> unrolling loops and vectorization...