This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SPEC2000 comparison of LLVM-3.2 and coming GCC4.8 on x86/x86-64
On Thu, Feb 07, 2013 at 11:46:04AM -0500, Vladimir Makarov wrote:
> On 02/07/2013 11:09 AM, Richard Biener wrote:
> >On Thu, Feb 7, 2013 at 4:26 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
> >>I've add pages comparing LLVM-3.2 and coming GCC 4.8 on
> >>http://vmakarov.fedorapeople.org/spec/.
> >>
> >>The pages are accessible by links named GCC-LLVM comparison, 2013, x86 and
> >>x86-64 SPEC2000 under link named 2013. You can find these links at the
> >>bottom of the left frame.
> >>
> >>If you prefer email for reading the comparison, here is the copy of page
> >>accessible by link named 2013:
> >>
> >>
> >>Comparison of GCC and LLVM in 2013.
> >>
> >>This year the comparison is done on coming *GCC 4.8* and *LLVM 3.2*
> >>which was released at the very end of 2012.
> >>
> >>As usually I am focused mostly on the compiler comparison as
> >>*optimizing* compilers on major platform x86/x86-64. I don't consider
> >>other aspects of the compilers as quality of debug information
> >>(especially in optimizations modes), supported languages, standards
> >>and extensions (e.g. OMP), supported targets and ABI, support of
> >>just-in-time compilation etc.
> >>
> >>This year I did the comparison using following major options
> >>equivalent with my point of view:
> >>
> >>o *-O0 -g, -Os, -O1, -O2, -O3, -O4* for LLVM3.2
> >>o *-O0 -g, -Os, -O1, -O2, -O3, -Ofast -flto* for GCC4.8
> >On the web-page you say that you use -Ofast -fno-fast-math (because
> >that is what LLVM does with -O4). For GCC that's equivalent to -O3
> >(well, apart from that you enable -flto). So you can as well say you
> >tested -O3 -flto.
> I guess -Ofast -fno-fast-math is not just -O3 but you are right it
> is pretty close.
> >For 32bit you used -mtune=corei7 -march=i686 - did you disable
> >CPU features like SSE on purpose? Vectorization at -O3+ should
> >have used those (though without -ffast-math FP vectorization is
> >seriously restricted).
> Yes, I did it on purpose. Some 32-bit Linux distributions (e.g.
> Fedora) uses this architecture. Another reason is that I'd like to
> see how good compilers work with fp stack (I got an impression that
> LLVM generates less fp stack regs shuffles, so I think we could
> improve regstack.c). Although it is a dying architecture and
> probably we should pay more attention to SSE architectures
The FP stack is fortunately being put to rest in the museum of horrors.
This said for processors starting from the Pentium and until SSE2 (the
one with double precision) became available, the FXCH instruction was
made essentially free from an execution unit and timing point of view
(only taking a decoder slot). Stack shuffles implemented with the FXCH
instruction were the only way to extract parallelism from floating point
code. So as long as the stack shuffles are using FXCH, they are a valid
optimization, and only hint at some historical burden that LLVM never
has had to bear with.
Regards,
Gabriel