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