This is the mail archive of the 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: SPE configuration in GCC

>>>>> 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 
Mark> confusing.

	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.


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