This is the mail archive of the
mailing list for the GCC project.
Re: serious bugs in Altivec implementation of gcc
- From: Daniel Egger <degger at fhm dot edu>
- To: Eyal Bagon <eyal at mobileye dot com>
- Cc: GCC Developer Mailinglist <gcc at gcc dot gnu dot org>,Ilan Finci <Ilan dot Finci at mobileye dot com>,Aldy Hernandez <aldyh at redhat dot com>
- Date: 13 Aug 2002 16:39:15 +0200
- Subject: Re: serious bugs in Altivec implementation of gcc
- References: <3D57A1C6.firstname.lastname@example.org> <20020812104039.A24420@redhat.com> <3D58B420.email@example.com>
Am Die, 2002-08-13 um 09.24 schrieb Eyal Bagon:
> another thing that I noticed when comparing assembler code of 2
> corresponding files it looks like the new gcc code is less optimised
> ( I attached the testMax_2.9.2.cpp and testMax_3.2.cpp and their
> corresponding assembler files.
> I used : g++ -S -Wall -pedantic -ansi -Wno-long-long -DNDEBUG -O6
> -DALTIVEC -fvec testMax_2.9.2.cpp
> and : g++ -S -Wall -pedantic -ansi -Wno-long-long -DNDEBUG -O6 -DALTIVEC
> -maltivec testMax_3.2.cpp
Interesting. Your assembly produced by gcc 3.2 looks less optimal
because there's some additional code code generated to tell the OS
which vector registers to save on a context switch. Normally this is
only generated with -mabi=altivec and quite useless on Linux at least
because all AltiVec registers are saved.
I haven't played around with C++ and AltiVec yet and thus cannot comment
on the differences in the code generation between C and C++ but you
might want to use the former frontend for C code as it normally
generates better code if you restrict yourself to C features. Which OS
is this anyway?