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: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM


On Wed, Jun 25, 2014 at 4:00 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> On 2014-06-25, 5:32 AM, Renato Golin wrote:
>>
>> On 25 June 2014 10:26, Bingfeng Mei <bmei@broadcom.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.
>
>
>   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).

Richard.

>
>  I haven't dug deeper, though. Some of the differences
>>
>> were quite big, I'd be surprised if it all can be explained by
>> unrolling loops and vectorization...
>>
>


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