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

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.:

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

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. :slight_smile: