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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
