[llvm-commits] [llvm] r42285 - in /llvm/trunk/lib/Target/X86: X86FloatingPoint.cpp X86ISelLowering.cpp X86ISelLowering.h X86InstrFPStack.td X86InstrInfo.cpp X86InstrInfo.td X86InstrSSE.td X86InstrX86-64.td X86RegisterInfo.cpp

[Dan Gohman]

>>> +def X86cmp_new : SDNode<"X86ISD::CMP_NEW" ,     SDTX86CmpTest>;
>>
>> X86ISD::CMP_NEW SelectionDAG nodes return an i32 flags value,  
>> however the
>> corresponding X86cmp_new pattern-matching nodes use SDTX86CmpTest,  
>> which has
>> no result values. Is this intentional? If so, how is the discrepancy  
>> handled?
> 
> X86ISD::CMP_NEW does *not* return an flag result. It returns an result  
> in a physical register EFLAGS. It's up to the scheduler to ensure  
> nothing that can potentially modify EFLAGS is scheduled between  
> CMP_NEW and its users. The goal of what I've been doing is to  
> eliminate the need for the MVT::Flag hackery (which prevents SDNode  
> CSE, scheduling, etc.).

It returns an MVT::i32 flags result, rather than an MVT::Flag flags result.
Or at least, that's how I interpreted this code in X86ISelLowering.cpp:

    Cond = DAG.getNode(X86ISD::CMP_NEW, MVT::i32, Op0, Op1);

Now, X86InstrInfo.td has the following:

def SDTX86CmpTest : SDTypeProfile<0, 2, [SDTCisSameAs<0, 1>]>;
def X86cmp_new : SDNode<"X86ISD::CMP_NEW" ,     SDTX86CmpTest>;

At an initial glance, these are inconsistent. Does the

let Defs = [EFLAGS]

around each of the instructions that uses X86cmp_new automatically
get used for the result value of a node? That doesn't appear to be the
case in other instruction patterns that have implicit defs.

>>> +def : Pat<(parallel (X86cmp_new GR8:$src1, 0), (implicit EFLAGS)),
>>> +          (NEW_TEST8rr GR8:$src1, GR8:$src1)>;
>>
>> In the SelectionDAG IR, an SDNode can return multiple results.  
>> However, in
>> this GCC-RTL-like pattern langauge, where many things are supposed  
>> to directly
>> correspond to SelectionDAG counterparts, nodes can return at most  
>> one result.
>> They must be grouped together in a parallel to represent operations  
>> that have
>> multiple results. It seems like this will result in more  
>> discrepancies. Am I
>> misunderstanding something?
> 
> Again, no discrepancies. Instruction NEW_TEST8rr produces an implicit  
> result in EFLAGS. What the pattern is saying is the target independent  
> node expects the implicit result EFLAGS to be modeled as an explicit  
> result.
> 
> BTW, I intend to get rid of "parallel". I just haven't gotten around  
> to it.

Ok, cool. I'll take a closer look at this when it's ready.

Dan

-- 
Dan Gohman, Cray Inc.