On Tue, 2008-02-19 at 18:47 +0100, Jakub Jelinek wrote:
> On Mon, Feb 18, 2008 at 01:10:57PM -0800, Janis Johnson wrote:
> > 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.
>
> But non-generic vectors are still ABI incompatible, right?
> Say:
> typedef int v __attribute__((vector_size (16)));
> v foo (v a, v b)
> {
> return a + b;
> }
>
> has incompatible function argument passing and return value conventions,
> even with e.g. -m64 vs. -m64 -mcpu=970 (and the plan is to have the
> same between -m32 vs. -m32 -mcpu=970).
That's correct, and intended. The AltiVec ABI specifies that
vector types that map to AltiVec vector types are passed and
returned in vector registers. Without vector support they seemed
to be passed in rather random ways. No one has complained about
that in the last several years, and the documentation says that
it's not well-defined or stable, so we'll wait to fix that until
the PowerPC ELF ABI group recommends what to do.
The important issue about the ABI for right now is not argument
passing, but saving and restoring registers. As David points
out there is nothing that defines conventions for vector registers
if the AltiVec ABI is not used. He asked that enabling AltiVec
support, either with -maltivec or -mcpu=970 or configuring to use
vector hardware by default, defaults to using the AltiVec ABI to
avoid using surprises by users who have no idea their code is using
AltiVec hardware and needs the AltiVec ABI.
Janis
