On Sep 25, 2007, at 10:22 AM, Dan Gohman wrote: >> +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.). > > >> +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. Evan > > > Dan > > -- > Dan Gohman, Cray Inc. > _______________________________________________ > llvm-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits _______________________________________________ llvm-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
