>>> TEST-FAIL: cbe /External/SPEC/CINT2000/176.gcc/176.gcc >>> There are significant differences in the assembly output, but >>> this >>> test has been >>> failing similarly on recent (HEAD) nightly tests as well. >> >> This fails for me because the CBE doesn't implement the stacksave/ >> restore builtins right. If someone was interested in doing this, it >> should be possible to use GCC extensions to implement this. > > Is there a PR open for this?
No. It should be really easy to implement them in terms of GCC's __builtin_stack_save/__builtin_stack_restore builtins. I don't know what version of GCC these are available on though, we'd want to conditionalize the CBE output correctly. Filing a PR for this would make sense. >> >>> TEST-FAIL: jit /External/SPEC/CINT2000/186.crafty/186.crafty >>> Crash in the X86 code emitter due to inline asm: >>> lli: X86CodeEmitter.cpp:625: >>> void<unnamed>::Emitter::emitInstruction(const >>> llvm::MachineInstr&): Assertion `0 && "JIT does not support >>> inline >>> asm!\n"' failed. >>> These are coming from FD_ZERO, FD_SET and FD_ISSET macros used in >>> utility.c and >>> defined as inline ASM in /usr/include/bits/select.h on my >>> machine. >>> >>> TEST-FAIL: cbe /External/SPEC/CINT2000/186.crafty/186.crafty >>> I'm assuming the CBE didn't like inline ASM either. It >>> produced no >>> output. >> >> Ok, right. Can you send me the inline asm used, or just the >> entire .bc file? > > I attached the /usr/include/bits/select.h file from Linux. This is > mostly asm but I thought I'd give you the extra context since there > are > compiler differences for it. > > The raw bytecode for 186.crafty is also attached. Yuck. I was thinking that it would be something simple to pattern match like I did for bswap inline asm. It looks not worth it. -Chris _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
