Re: [commit] Use -mabi=altivec for AltiVec tests

[Daniel Jacobowitz <drow at false dot org>]

On Mon, Oct 29, 2007 at 06:57:47PM +0100, Ulrich Weigand wrote:
> > For now, what do you think we should do about the option?  Restrict it
> > to Linux?
> 
> I think we should leave the option in, but for Linux only -- using 
> -mabi=altivec is supposed to work on Linux, and using it has the
> effect of not only reducing testsuite FAILs, but actually in fact
> testing the existing GDB code paths.
> 
> That is, unless we go right ahead and check your ABI detection
> patch in; this would solve the problem in an even better way ...
> 
> Would you like me to check in the temporary fix, or would you 
> prefer to simply check in your patch?

I think I will check in my patch, but reduce the number of test
cases a bit.  I'd like to test only two: -mabi=altivec + "set powerpc
vector-abi altivec", and -mabi=altivec + "set powerpc vector-abi
auto".  The former should always pass.  The latter will pass if GCC
and LD are new enough.  Sound OK?

I don't want to test the non-AltiVec-ABI bits because they do not seem
to be sensibly defined.  I filed PR 33899 last week, which shows
the -mabi=no-altivec ABI changing based on -maltivec.  We can't and
shouldn't detect that.

> However, we should keep in mind the goal of being able to link
> code built with -mabi=altivec and code built with -mabi=no-altivec,
> as long as the interfaces between the two do not involve vector types.
> This implies that -mabi=altivec and -mabi=no-altivec at least agree
> on which registers are considered call-saved and which are considered
> call-clobbered.  Your patch would break that.
> 
> I'd suggest to either keep this part of the ABI unchanged between the
> two, i.e. save/restore vr20..vr31 even in -mabi=no-altivec mode; or
> else (if saving/restoring proves difficult), treat vr20..vr31 as 
> completely reserved and never use them, as is done by current GCC
> mainline for AltiVec on AIX.

Right.  I thought about this for a couple of days, and we should be
able to save and restore them.  There's no reason it has to be
predicated on -mabi=altivec.

Of course, any existing -maltivec -mabi=no-altivec code will still
have to be rebuilt.  It's terminally broken.

-- 
Daniel Jacobowitz
CodeSourcery