[llvm-commits] [llvm] r91381 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h lib/Target/X86/X86Instr64bit.td lib/Target/X86/X86InstrInfo.td test/CodeGen/X86/setcc.ll

[Dan Gohman]

On Dec 15, 2009, at 10:36 AM, Evan Cheng wrote:

> 
> On Dec 15, 2009, at 10:30 AM, Dan Gohman wrote:
> 
>> 
>> On Dec 14, 2009, at 4:53 PM, Evan Cheng wrote:
>>> 
>>> ==============================================================================
>>> --- llvm/trunk/lib/Target/X86/X86Instr64bit.td (original)
>>> +++ llvm/trunk/lib/Target/X86/X86Instr64bit.td Mon Dec 14 18:53:42 2009
>>> @@ -1333,6 +1333,15 @@
>>>                                    X86_COND_NO, EFLAGS))]>, TB;
>>> } // isTwoAddress
>>> 
>>> +// Use sbb to materialize carry flag into a GPR.
>>> +let Defs = [EFLAGS], Uses = [EFLAGS], isCodeGenOnly = 1 in
>>> +def SETB_C64r : RI<0x19, MRMDestReg, (outs GR64:$dst), (ins),
>>> +                  "sbb{q}\t$dst, $dst",
>>> +                 [(set GR64:$dst, (zext (X86setcc_c X86_COND_B, EFLAGS)))]>;
>> 
>> An sbbq will set all 64 bits. Why does the pattern here have a zext in it?
> 
> X86setcc_c like X86setcc returns a i8 value. Yes, the semantics of is all zero or all one's. That's why x86isellowering will and the result with 1.

Whatever X86setcc_c is, the current pattern doesn't describe the instruction.
The pattern says the instruction will always set the most significant bits of
the output to zero, and that's not what the instruction really does.

Dan