clang crash on "x" constraint for athlon-xp
Bruce Evans
brde at optusnet.com.au
Fri May 24 08:07:08 UTC 2013
Why does clang -march=athlon-xp abort on this?
@ #include <xmmintrin.h>
@
@ void
@ foo(void)
@ {
@ __m128 x;
@
@ asm("" : "=x" (x));
@ }
@ SplitVectorResult #0: 0x2a190228: v16i8 = Register %vreg1 [ORD=1] [ID=0]
@
@ fatal error: error in backend: Do not know how to split the result of this operator!
@
@ cc: error: clang frontend command failed with exit code 70 (use -v to see invocation)
@ FreeBSD clang version 3.3 (trunk 178860) 20130405
@ Target: i386-unknown-freebsd10.0
@ Thread model: posix
@ cc: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
@ cc: note: diagnostic msg:
@ ********************
@
@ PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
@ Preprocessed source(s) and associated run script(s) are located at:
@ cc: note: diagnostic msg: /tmp/z-SmXpwL.c
@ cc: note: diagnostic msg: /tmp/z-SmXpwL.sh
@ cc: note: diagnostic msg:
@
@ ********************
clang also fills up /tmp with these files.
gcc -march=athlon-xp works, and so does clang -march=athlon64.
athlon64 has SSE1 and SSE2; athlon-xp only has SSE1. The above is trying
to use only SSE1 features.
I don't really understand <xmmintrin.h> and am using it here just to
declare __m128. Perhaps it can do what I want without any asm. This
is to take an 8-byte double and split it into 2 integers using SSE*,
and vice versa. SSE* must be used on 32-bit systems since compilers
still don't understand how to unpack and repack 64-bit objects efficiently
using integer instructions (loads and stores must be 64 bits). I also
need this for 10-byte long doubles. Raw asm is needed for 2 bytes of
these, and it would be hard to combine this with any intrinsics.
While here, I will re-report another clang asm problem:
@ double_t dt;
@ double d;
@
@ __asm("" : "=t" (d) : "0" (dt));
This works with gcc, but fails (generates a store-load of d, but the
whole point of this null asm is to avoid this store-load by pretending
that the asm does it) with clang. If the constraints are changed to
"=&t" and "t", then it works for clang but fails (with constraint
and/or reload errors) with gcc.
Bruce
More information about the freebsd-numerics
mailing list