This is the mail archive of the
gcc@gcc.gnu.org
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: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, Renato Golin <renato dot golin at linaro dot org>, Bingfeng Mei <bmei at broadcom dot com>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, "gcc.gcc.gnu.org" <gcc at gcc dot gnu dot org>
- Date: Wed, 25 Jun 2014 16:05:46 +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> <53AAD61A dot 6010201 at redhat dot com> <CAFiYyc06sL1bYpGAutTWNs1PD9OCMXT_qpCoTT_b6+2y02Dhgg at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Jun 25, 2014 at 04:02:49PM +0200, Richard Biener wrote:
> > That might be a consequence of difference in aliasing I wrote about. I
> > looked at the code generated by LLVM and GCC of an interpreter and saw
> > bigger code generated by GCC too.
> >
> > A sequence of bytecodes execution and each bytecode checks types of
> > variables (small structure in memory) and set up values and types of results
> > variables. So GCC was worse to propagate the variable type info (e.g. int)
> > in the bytecode sequence execution where it would be possible and remove
> > unnecessary code (cases where other types, e.g. fp, is processed). LLVM was
> > more successful with this task.
>
> Maybe LLVM is just too aggressive here (but is lucky to not miscompile
> this case).
Or just doesn't consider all stores as possibly changing the effective type,
only real placement new and first store to newly allocated heap memory?
Guess it would be nice to try a few simple testcases...
Jakub