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

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

In D59744#1549746 <https://reviews.llvm.org/D59744#1549746>, @hans wrote:

> In D59744#1549675 <https://reviews.llvm.org/D59744#1549675>, @wxiao3 wrote:
>
> > Can anyone provide me some small reproducers code for the issue tripped over by Chromium / Skia?
>
>
> Sorry, I don't have a small repro yet. I'm still working on finding out exactly what's happening in Chromium, but it's a large test. It's easy to find where the x87 state gets clobbered after your change, but I haven't found what code was depending on that state yet.


Oh, I thought the problem was just that the registers alias, not that the whole x87 state gets messed up by mmx instructions. Here's a simple repro:

  $ cat /tmp/a.c
  #include <stdint.h>
  #include <stdio.h>
  
  #ifdef __clang__
  typedef uint16_t __attribute__((ext_vector_type(4))) V;
  #else
  typedef uint16_t V __attribute__ ((vector_size (4*sizeof(uint16_t))));
  #endif
  
  V f() {
    V v = { 1,2,3,4 };
    return v;
  }
  
  double d() { return 3.14; }
  
  int main() {
    f();
    printf("%lf\n", d());
    return 0;
  }
  
  $ bin/clang -m32 -O0 /tmp/a.c && ./a.out
  -nan

Before your change, it prints 3.140000.

Chromium was previously working around this problem in gcc by force-inlining f() into main(). That doesn't work with Clang because it touches %mm0 even after inlining.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59744