[LLVMdev] TableGen: Avoid/Ignore the "no immediates on RHS of commutative node" constraint.

[Stephen McGruer]

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>