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

[Zack Weinberg <zack at codesourcery dot com>]

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.

zw