Stephen McGruer
2012-Jan-14 22:35 UTC
[LLVMdev] TableGen: Avoid/Ignore the "no immediates on RHS of commutative node" constraint.
Ivan, Sorry, no, I wasn't clear enough. Both "op dst_reg,immediate,src_reg" and "op dst_reg,src_reg,immediate" are allowed in the ALU ops. For most instructions these are two different things - e.g. sub a,5,b is different from sub,a,b,5 obviously - but for things like add they just define the same thing. My problem is that LLVM won't allow immediates on the LHS of nodes so I am forced to have a non-clean layout due to TableGen issues. Aside from my disliking that I have to care about a TableGen restriction like that, I was looking to see if there was a better solution to the problem than using nested multiclasses like I showed. Stephen PS: Your message was off-list - I wasn't sure if that was deliberate and I thought that I should make the matter clear for anyone else, so I cc'd the list back in. I hope you do not mind. :) On 14 January 2012 22:21, Ivan Llopard <ivanllopard at gmail.com> wrote:> Hi Stephen, > > > On 14/01/2012 21:26, Stephen McGruer wrote: > >> Dear all, >> >> I was wondering if it is possible in TableGen to either: >> >> 1. Selectively define an instruction depending on an SDNode's >> properties, e.g. if the SDNode is not commutative. >> 2. Override/ignore the TableGen error given when a commutative node has >> an immediate on the LHS. >> >> My case comes from trying to define a generic ALU operation multiclass >> for my target, which includes a "dest_reg,immediate,src_reg" format. >> This is disallowed for commutative SDAG nodes (e.g. 'add') in LLVM, as >> the RHS cannot be an immediate (I assume for optimization purposes). I >> think I could achieve this with nested multiclasses, e.g.: >> >> > If your target supports only additions with immediates in LHS, it is just > an asm printing issue if I understand your problem correctly. You can just > print out your immediate where you want it to be printed. For example: > > def ADDLHSImm: Instruction { > let OutOperandList = (outs R:$dst); > let InOperandList = (ins R:$src, i32imm:$b); > let AsmString = "add $dst, $b, $src"; > let Pattern = (set R:$dst, (add R:$src, imm:$b); > } > > Because "add" is commutative, the instruction selector will have both > patterns to match, one with LHS as an immediate and the other one with RHS > as an immediate. > > Regards, > Ivan > > multiclass ALUOp<..> { >> ... >> } >> >> multiclass ALUOp_not_comm<..> { >> defm : ALUOp<...>; >> >> // Plus the 'dest_reg,immediate,src_reg' format. >> } >> >> defm ADD : ALUOp<..> >> defm SUB : ALUOp_not_comm<..> >> >> >> But this feels slightly dirty to me, not to mention more annoying to >> maintain (since in my target's eyes there is no difference between the >> formats for ADD and SUB), so I just wanted to check if there was any way >> to avoid this. >> >> Thanks, >> Stephen >> >> >> ______________________________**_________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120114/2403d4b1/attachment.html>
Reasonably Related Threads
- [LLVMdev] TableGen: Avoid/Ignore the "no immediates on RHS of commutative node" constraint.
- [LLVMdev] Intrinsic's "Commutative" property
- [InstCombine] Addrspacecast and GEP assumed commutative
- [InstCombine] Addrspacecast and GEP assumed commutative
- [LLVMdev] bitwise AND selector node not commutative?