PATCH [mainline] rewrite of altivec.h to improve cpp performance

[Aldy Hernandez]

> >> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00791.html
> >> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00820.html
> >>
> >> Given that the changes to target-independent code are small and the
> >> enormous macro expansions that are inevitable when the macros have
> >> expansions that contain any parameter name more than once are clearly a
> >> bug, I'd think such a change would be reasonable at the present
> >> development stage.
> >
> > Agreed. In fact, Apple's 3.3 implementation of Altivec is along this
> > line. But such implementation was turned down in the past I was
> > told. My patch is a stop-gap measure at this time. Also, we are at
> > Stage 3 and I don't think such large changes will make it in at this
> > time.
> 
> I am not going to approve this unilaterally, but I agree with Joseph
> that changes like this are reasonable at the present development
> stage.  It is textually large, but it affects only altivec.h, so the
> risk of the change is limited to users of the feature you're trying to
> improve; that's exactly the right tradeoff to be making at this stage.

Arghhh.  I'm going to have to implement rth's suggestion since Bonzini
bailed on us ;-).  Altivec.h needs a good rewrite.

In the meantime, Fariborz's suggestion is good enough for 4.0.  Do not
take this as an approval, I'll go through your patch this weekend.

Thanks.
Aldy