>>> +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. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits