PowerPC ABI impact of -mvsx / -mno-vsx

Hal Finkel hfinkel at anl.gov
Tue Jul 8 12:00:52 PDT 2014

----- Original Message -----
> From: "Ulrich Weigand" <Ulrich.Weigand at de.ibm.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Commits" <llvm-commits at cs.uiuc.edu>
> Sent: Tuesday, July 8, 2014 11:38:09 AM
> Subject: PowerPC ABI impact of -mvsx / -mno-vsx
> 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?

Yes, I believe this is a bug. We should pass v2[if]64 types in vector registers regardless of whether or not VSX support is enabled.

>  Would it be difficult to enable
> v2i64 / v2f64 parameter passing in vector registers?

I'm not sure how easy it will be. One option is to declare those types as legal, but all operations on those types as Expand. If it works, that's probably the easiest option. Another options is to adjust the ABI code to deal with this directly. I think this is possible because the ABI code always has the original IR-level types, but I've not thought through any of the details.

Thanks for bringing this up. I think that Bill pointed this out to me at the time, but we never followed through on fixing it.


> 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

Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-commits mailing list