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

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> My understanding (courtesy of Geoff Keating) is that on most PowerPC
> targets this only affects the passing of vector registers.  On some
> (powerpc-eabi; I am not sure if there are others, but I do not know
> of any) it increases the required stack alignment.  If your CRT files
> don't do this, then saving the vector registers may do bad things
> to your stack frame.

Yes, that was my understanding as well.

> 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?

> http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00438.html
> 
> Perhaps I should ping that now that the .gnu_attribute bit went in
> separately.  Actually, no, the patch predated my improved
> understanding of the stack alignment magic.  It might be right
> for powerpc-eabi, but powerpc-linux actually does have a sufficiently
> aligned stack so it ought to save them properly.

OK, I see.  That is indeed a serious bug; I wasn't aware of that.
It would appear that the ABI defined by -mabi=no-altivec is currently
inconsistent with itself, so this absolutely needs to be fixed.

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.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com