This is the mail archive of the gcc-patches@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]

[PATCH]: RFC: Add power7 support to the rs6000 (12 parts)


I will submit as 12 parts the patches to add power7 support to the rs6000
port.  I realize some people will be away from email because of the GCC summit
next week, but I thought I would post these patches to get comments.  I would
like to get these patches checked in.

I've done lots of testing of these patches in the 4 months I've been working on
them in the power7-meissner branch (bootstrap, regression tests, running spec
2006, etc. on both current power machines and on processors that support the
VSX instructions).  I believe there is more work to be done on power7, but I'm
at a good stopping point right now.

I built a powerpc-spe-eabi cross compiler, and ran a vector test through it
that tries every single operation and sees whether the compiler vectorizes it
or not.  My patches generate exactly the same code as the mainline compiler I
was testing again (subversion version 148152) from Tuesday June 3rd.  I did
discover a problem in both the mainline and my patches if the compiler is
trying to vectorize a powf (a[i], 0.5f) into sqrt on the SPE.

I should mention that the spec 2006 calculix benchmark won't build at the
moment due to a validation error in the vectorization code if checking is
enabled.

Some of the things We've done in these patches include:

1) Pass the appropriate switches to the assembler if you use -mcpu=native;

2) We moved a lot of code that was executed at runtime into arrays that are
   calculated at initialization time.

3) We moved most of the vector expanders from altivec.md to vector.md so that
   they can generate either VSX or Altivec instructions.  In theory the SPE
   vector instructions could be folded into this framework, but I didn't want
   to modify code I can't really test.

4) We added a vsx.md file to add the vsx instructions, and a power7.md file for
   power7 tuning.

5) I added new debug switches:
	-mdebug=cost	Debug the rtx cost functions
	-mdebug=addr	Debug the various address mode support
	-mdebug=reg	Debug the register class information

6) I added a new print_operand % code (%x) to print VSX registers (VSX
   registers are  supersets of both the traditional floating point registers
   and the Altivec registers, so altivec register 0 is VSX register 33).

7) I rewrote the altivec vector predicate code because I really, really did not
   like the way it was implemented, passing the instruction to generate code
   for as a SYMBOL_REF.  Instead I wrote to use UNSPEC and rtx code.

8) I rewrote the vector conditional code in altivec so that it actually had the
   RTL test in it rather than just using UNSPEC.

9) I provided a real binutils release number instead of 9.99.0 for the
   assembler tests.

10) I added support for the new power7 popcntd/popcntw/bpermd instructions in
    addition to the VSX instructions.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com


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