Re: [Bug target/15106] Vector varargs failure for AltiVec on ppc32 linux

[Alan Modra <amodra at bigpond dot net dot au>]

On Tue, Apr 27, 2004 at 02:43:45PM +0200, Hartmut Penner wrote:
> > > @@ -4481,7 +4481,7 @@ function_arg (CUMULATIVE_ARGS *cum, enum
> > >           n_words = rs6000_arg_size (mode, type);
> > >
> > >         /* Long long and SPE vectors are put in odd registers.  */
> > > -       if (n_words == 2 && (gregno & 1) == 0)
> > > +       if (n_words >= 2 && (gregno & 1) == 0)
> > >           gregno += 1;
> 
> > This I disagree with.  It changes the calling convention for -m32
> > -mno-altivec -mabi=no-altivec functions that use vector args, both
> > varargs and non-varags.
> 
> I don't think, there are any libs out there having vector args and been
> compiled with -mno-altivec -mabi=no-altivec. The ABI also states nothing
> about this case. That means, we would not break anything. And it does not
> make sense, that long longs have a higher aligment than 128 bit vectors.

Hmm, after looking at latest passee_1.o, I think you do need to do
something like this for -maltivec -mabi=no-altivec.  The problem is
that in this case (va_arg access to a vector type), an altivec insn is
used to load out of the parameter save area.  That requires 16 byte
alignment.  So firstly we need to ensure the stack is 16 byte aligned,
and secondly we need to ensure that the offset into the parm save area
is 16 byte aligned.  A 16 byte aligned offset means that we need to
choose r5,r6,r7,r8 to pass a vector in gprs.

If you can't guarantee stack alignment then you'd need to create an
aligned stack temp and shuffle data through it to the vector register.
That's horrible.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre