[llvm-commits] CAST patch committed

[Chris Lattner]

>>> 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