[PATCH] D59744: Fix i386 ABI "__m64" type bug

Tue Jun 18 10:24:56 PDT 2019

rjmccall added a comment.

In D59744#1548540 <https://reviews.llvm.org/D59744#1548540>, @mtklein wrote:

> Hey folks, I'm the Skia point of contact on this, and "luckily" the person who wrote all the code that got us into this mess.  Let me cross post a couple questions I've had from the Chromium bug over here where folks might know the answer...
>
> Now that Clang's decided to match GCC's behavior of using mm0 to pass around 8-byte vectors on x86-32, is there any way to use 8-byte vector types safely any more?  I don't really have the full context of this Clang change, but is it maybe a good idea applied to too many types?  I notice the change mentions __m64, but here I'm using uint16_t ext_vector_type(4) exclusively, never __m64 or even an 8x8 vector... can we just squint and say u16x4 and __m64 aren't the same, passing __m64 according to the ABI but vector extensions however we were doing it before?

`__m64` is of course defined using the compiler's vector extensions.  More importantly, GCC also has those vector extensions (or at least some of them), and my understanding is that GCC is interpreting the ABI's  `__m64` to mean "all 8-byte vectors" (which seems quite reasonable to me), and that's what Clang needs to stay compatible with on systems where GCC is the system compiler.

Now, we could theoretically use a different ABI rule for vectors defined with Clang-specific extensions, but that seems like it would cause quite a few problems of its own.

> In short, should working with 4x u16 be safe on x86-32 and there's a bug / undefined behavior in my code leading to this  mm0/st0 clobber, or is this just actually not really spec'd to work?

It's always possible that there's a bug in the compiler, but the most likely thing is that you have assembly code that's not obeying the ABI in some way.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59744/new/

https://reviews.llvm.org/D59744