Evan Cheng wrote:> On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: > >> Is there some optimizer knob I'm not turning properly? In more complex >> cases, GCC does poorly with two-address operand choices and so bloats >> the code with unnecessary register moves. I have high hopes LLVM >> can do better, so this result for a simple case is bothersome. >> > > Are you marking add as commutable? Are you making mov as a copy > instruction? >How do I mark them? For the commutative property, I observed this definition: def add : SDNode<"ISD::ADD" , SDTIntBinOp , [SDNPCommutative, SDNPAssociative]>; ... and assumed it was sufficient, since I saw no other targets making special arrangements. I see no obvious (to me, anyway 8^) "copy instruction" property. The insn in question is generated by copyRegToReg(), and satisfies the isMoveInstr() predicate. G
Hello, Greg> ... and assumed it was sufficient, since I saw no other targets making > special arrangements.You need to mark you instruction as commutative. Almost all targets do this. Something like this: let isCommutable = 1 in { // X = ADD Y, Z == X = ADD Z, Y def ADD16rr : Pseudo<(outs GR16:$dst), (ins GR16:$src1, GR16:$src2), "add.w\t{$src2, $dst|$dst, $src2}", [(set GR16:$dst, (add GR16:$src1, GR16:$src2)), (implicit SR)]>; } -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.
On Apr 16, 2009, at 4:25 PM, Greg McGary wrote:> Evan Cheng wrote: >> On Apr 16, 2009, at 3:17 PM, Greg McGary wrote: >> >>> Is there some optimizer knob I'm not turning properly? In more >>> complex >>> cases, GCC does poorly with two-address operand choices and so >>> bloats >>> the code with unnecessary register moves. I have high hopes LLVM >>> can do better, so this result for a simple case is bothersome. >>> >> >> Are you marking add as commutable? Are you making mov as a copy >> instruction? >> > > How do I mark them? For the commutative property, I observed this > definition: > > def add : SDNode<"ISD::ADD" , SDTIntBinOp , > [SDNPCommutative, SDNPAssociative]>;Yes, the "target-independent" ISD::ADD node is commutative. But it doesn't mean the target specific instruction it is selected to has to be commutative.> > ... and assumed it was sufficient, since I saw no other targets making > special arrangements.In X86InstrInfo.td, ADD32rr (and lots others) are marked isCommutable. Evan> > I see no obvious (to me, anyway 8^) "copy instruction" property. The > insn in question is generated by copyRegToReg(), and satisfies the > isMoveInstr() predicate. > > G > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev