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

[Mark Mitchell <mark at codesourcery dot com>]

Zack Weinberg wrote:

> Fariborz Jahanian <fjahanian@apple.com> writes:
>
>  
>
> > On Sep 10, 2004, at 9:24 AM, Joseph S. Myers wrote:
> >
> >    
> >
> > > There have been some proposed patches to add a target hook to
> > > facilitate
> > > overloaded built-in functions.  I think that's the only way to
> > > address the
> > > underlying problem rather than just some of the symptoms in some cases.
> > > (But if you don't want to make such a bigger change, addressing the
> > > symptoms is itself a useful improvement.)
> > >
> > > 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.
>  
Yes; I think this is exactly the right approach, and it is up to the 
PowerPC maintainers to decide if they want to accept this patch.

--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com