mtklein added a comment.
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? Or can we work out some sort of ABI that preserves st0/mm0?
I think we're finding that even with forced-inlining, at -O0 we still end up
getting u16x4 values stored in mm0 briefly (kind of roundabout through xmm
registers and the stack once or twice too).
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?
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
