Project submission for GCC 4.1 - AltiVec rewrite

[Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>]

I had already submitted this to Mark, but since I have improved a few 
rough spots in the code I think it's better to make it public.

> * Project Title

AltiVec rewrite.

> * Project Contributors

Paolo Bonzini

> * Dependencies

none

> * Delivery Date

March 15th or earlier (the implementation is complete and has no 
regressions).

> * Description

The project reimplements the AltiVec vector primitives in a saner way,
without putting the burden on the preprocessor and instead processing
the "overloading" in the C front-end.

This would benefit compilation speed on AltiVec vector code, and move
the big table of AltiVec overloading pairs from an installed header
file to the compiler (an 11000-line header file is reduced to 500 lines
plus 2500 in the compiler).

The changes are so far self contained in the PowerPC backend, but I
would expect that a hack that I am using will require to be changed upon
review.  Unfortunately, a previous RFC I posted on the gcc mailing list
had (almost) no answer.

I plan to take a look at apple-ppc-branch, which supposedly does not 
need this hack, or to ask for feedback when I submit the project.

The current implementation improves the existing implementation in that
anything but predicates will accept unparenthesized literals even in C.
This line:

  vec_add (x, (vector unsigned int) {1, 2, 3, 4})

now fails in C and works in C++, but with the new implementation would 
work in C as well.  On the other hand, using a predicate like this

  vec_all_eq (x, (vector unsigned int) {1, 2, 3, 4})

will still not work in C (it will *not* be a regression in C++, where it 
will be okay both without and with my changes).  It would have to be 
written as

  vec_all_eq (x, ((vector unsigned int) {1, 2, 3, 4}))

exactly as in the current implementation.

Paolo