On Mon, 2008-02-18 at 15:25 -0500, Jakub Jelinek wrote: > On Mon, Feb 18, 2008 at 09:29:22AM -0800, Janis Johnson wrote: > > PR target/34526 doesn't show up as a regression but it is in that > > on powerpc-linux "-O3 -mcpu=970" now includes -ftree-vectorize > > and with the default, non-AltiVec ABI vector registers can be > > clobbered by other functions in the same call tree. An example > > of this is 176.gcc from SPEC CPU2000. > > > > The fix at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00094.html > > introduces a regression by exposing an existing bug in varargs > > passing of generic vectors with "-mno-altivec -mabi=altivec". I'm > > still trying to get that fixed (delayed last week by father's > > surgery and daughter's wedding), but even if the fix doesn't make > > it in time the fix for vectorization is much more important than > > breakage to functionality that probably isn't used in the real world. > > I'd like to understand what exactly would defaulting to the Altivec > ABI for ppc-linux mean. -mabi=altivec passes some types of vectors > in Altivec registers, but you can hardly pass anything in those registers > if the CPU doesn't support the Altivec ISA. So, would -m32 be ABI > incompatible with -m32 -mcpu=970 e.g.? > And, will we have still a possibility to choose a broken setup (ATM > -m32 -maltivec, in the future -m32 -maltivec -mabi=no-altivec)? By broken > I mean that if the code works, it is just by luck; Altivec registers > are neither call-used nor call-saved nor fixed. > I'd like to understand why -m32 -maltivec when -mabi=altivec is not > requested can't make all altivec registers call-used. Whether something > is call-saved is a part of ABI, you need to save the call-saved registers > in the call frame and have unwind info which can restore them. > The non-altivec ABI doesn't mention the Altivec registers (it predates > them), so they are not call-saved. But saying that they aren't call-used > is wrong, when functions don't save them. > What would break if in non-altivec ABI all Altivec registers are either > fixed (-mno-altivec) or call-used (-maltivec)?
With -mno-altivec, types defined with __attribute__((vector_size(16))) are not mapped to AltiVec vector types. When -mabi=altivec is used without AltiVec hardware support, there are no AltiVec vector types to pass as arguments and they are passed in other ways, which are kind of broken and ought to be fixed eventually (see PR34526) but the code works. With -maltivec -mabi=no-altivec, AltiVec vectors are passed by reference or on the stack or in general registers. Except for variable argument lists, this works. The problem is that the non-AltiVec ABI doesn't call for saving and restoring AltiVec registers, and other people's attempts to fix that have failed; that information is from IRC, I don't remember who tried. Fixing that would certainly be the best option, but I tried for something simpler. Unfortunately changing the default ABI exposed the va-arg-25.c failure and investigation of that made me realize that argument passing and function return is not consistent for generic vectors with and without the AltiVec ABI (PR target/33899). I changed argument passing and function return of generic vectors to be consistent with and without the AltiVec ABI for powerpc-linux and powerpc64-linux, but in so doing inadvertently changed the behavior for other powerpc targets as well. Meanwhile the trunk has been more and more frozen, so the latest attempt is to switch the default ABI with as little other change as possible. For what it's worth I now have a minimal hack to fix va-arg-25.c. For GCC 4.4 I'd like to get input from the people involved with the PowerPC-32 and -64 ELF ABIs to regularize passing of generic vectors. I can look into saving and restoring registers with -maltivec -mabi=no-altivec but that's likely to take me awhile. Janis
