This is the mail archive of the
mailing list for the GCC project.
Re: SPE configuration in GCC
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, aldyh at redhat dot com
- Date: Mon, 17 Jan 2005 12:15:54 -0500
- Subject: Re: SPE configuration in GCC
- References: <41EBED9D.firstname.lastname@example.org>
>>>>> Mark Mitchell writes:
Mark> For most target architecture families, you can generate code for all
Mark> processors in the family, independently of how you configured GCC. For
Mark> example, even if you build for a little-endian MIPS 4kc processor, you
Mark> can still generate code for a big-endian MIPS R10k. You may not have
Mark> runtime libraries that work, but you can generate the code.
Mark> I was surprised to find that configuring for powerpc-unknown-linux-gnu
Mark> got me a compiler that could not generate SPE code becausing things like
Mark> TARGET_SPE are hardwired to zero. Is there a reason not to have
Mark> TARGET_SPE defined to rs6000_spe in rs6000.h? My expectation would be
Mark> that the defaults for these variables would be set differently in
Mark> linuxspe.h, but that they would be accessible in all configurations.
Mark> Right now, so far as I can tell, the PowerPC back end simply ignores
Mark> things like -mfloat-gprs= in its default configuration, which is very
The rs6000 port now includes a number of architectures and
architectural features that cannot exist for some target configurations.
With GCC's genconditions infrastructure, setting the options to constant
zero allows the patterns to be omitted and the compiler to optimize out
tests, speeding up the compiler.
Kumar will be happy to know that TARGET_POWER already is zeroed
for all sysv4.h PowerPC targets so SPE targets symmetrically are not
bloated with POWER architecture features. TARGET_POWER is disabled for
Darwin as well. TARGET_ALTIVEC similarly is zeroed for other
configurations where appropriate.