PowerPC ABI impact of -mvsx / -mno-vsx

[Ulrich Weigand]

Hi Hal,

in running various ABI tests I ran into an issue relating to v2i64 / v2f64
types.  While you cannot use regular VSX types (vector double etc.) when
VSX is not supported, you still can define types that look just like those
using attribute ((vector_size)).

When you do that, however, LLVM will currently pass those types differently
depending on whether VSX is supported or not; they will reside in vector
registers if VSX is supported, and in GPRs if not.  This has the effect
that -mvsx becomes an ABI-changing option ... I'm not sure this is really
the expected result.

In principle, it should be perfectly possible to pass v2i64 / v2f64 in
vector registers even if VSX is not supported; the only operations strictly
required would be to move the values in and out of the registers used for
parameter passing, and you can use plain Altivec instructions for those.

However, that doesn't work since v2i64 / v2f64 are not even legal types if
VSX is not supported, and thus common SelectionDAG code will simply
scalarize them.

Given that you implemented the current VSX support: any thoughts on that?
Is this something we should address?  Would it be difficult to enable
v2i64 / v2f64 parameter passing in vector registers?


Here's a example showing the different ABI based on -mvsx / -mno-vsx:

typedef unsigned long v2di __attribute__((vector_size (16)));
v2di g;

void callee (v2di x)
{
  g = x;
}

int test (v2di x);
void caller (void)
{
  test (g);
}


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand | Phone: +49-7031/16-3727
  STSM, GNU/Linux compilers and toolchain
  IBM Deutschland Research & Development GmbH
  Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
  Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294