[LLVMdev] Multi-instruction patterns, tablegen and chains

[Matthijs Kooijman]

Hi Dan,

> But from your earlier description, MOVE didn't need a chain, only RD  did.
> So even there, it sounds like tablegen isn't doing exactly what you  want.
Yeah, but I think an extra chain is something I can live with for now, but a
missing chain is a problem :-)

Anyway, I found another somewhat-working workaround. I created dummy SDNode
defs that the SDNPHasChain set to the correct value, and a pattern for the
MOVE and RD instructions that used those SDNodes. Because the nodes were dummy
(referring ISD::DELETED_NODE), I could be sure they would never match, while
they would still transfer the correct chain property to the instruction
itself.

This took a considerate amount of tweaking, because even for these dummy nodes
tblgen insisted that the types would be correct. This resulted in the
following SDNodes:

	def dummy_rd    : SDNode<"ISD::DELETED_NODE", SDTRead, [SDNPHasChain]>;        
	def dummy_move  : SDNode<"ISD::DELETED_NODE", SDTRead, []>;                    
	def dummy_intop : SDNode<"ISD::DELETED_NODE", SDTIntLeaf, []>;

and these patterns for the MOVE and RD instructions resp.

	(set DatapathReg:$dst, (dummy_move dummy_intop:$src))

	(set Bus:$dst, (dummy_rd dummy_intop:$addr))

Now, my multi-instruction pattern correctly matches and produces the proper
chain results:

	def          : Pat< (rd imm:$addr),
											(MOVE (RD imm:$addr))
										>;

So that got me where I thought I wanted to be, but then the scheduler started
messing up things. There are some constraints between the MOVE and RD
instructions, which are probably best modeled by connecting by a Flag.

Adding a SDNPInFlag property to the dummy_rd and SDNPOutFlag to dummy_move
didn't quite help: The code generated for the Pat was unaffected, the code
generated for the Instruction pattern for RD was now broken, I suspect that RD
was producing too many values (ie, there was no getTargetNode to handle this
case yet).

In the end, I settled for doing custom selection copying most code from my
last attempt and manually adding a Flag operand/result to that code. This
seems to work and actually produce working code (for the two instructions I've
implemented so far...).

Now I'll be continuing to see if other funkyness of our architecture can be
properly modeled by LLVM...

Thanks for the pointers!

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081110/d4aeb929/attachment.sig>