[LLVMdev] Multi-instruction patterns, tablegen and chains

[Dan Gohman]

On Nov 4, 2008, at 12:12 AM, Matthijs Kooijman wrote:

> Hi Dan,
>
>> Having tblgen pretend that the MOVE isn't the root seems a bit
>> counter-intuitive though.
> I didn't really mean making RD the root, but rather telling tablegen  
> that RD
> is the "primary" node, corresponding to the input pattern. This  
> would allow
> the properties of the input rd SDNode be properly transferred to the  
> output RD
> node instead of the MOVE node. I doubt this is a very elegant  
> solution, nor
> will it work in the general case, but this is what I meant anyway.

Ok. I agree, not very elegant, but you may be able to come up with  
something
good enough for whatever prototyping you're doing without too much extra
effort.

>
>
>> I think it would be useful to have a way to explicitly tell
>> tblgen which node(s) in the output pattern to hook up the chain(s)
>> to. I believe this is related to a problem David Greene is seeing,
>> where he has a case involving multiple chains.
>> A fully general approach would be to make chain operands explicit
>> in patterns, and to invent some syntax for identifying chain
>> results. It might look something like this:
>>
>> def : Pat<(rd ch:$input_chain, imm:$addr)[$output_chain],
>>           (MOVE (RD ch:$input_chain, imm:$addr)[$output_chain])>;
>>
>> This would be a pretty big change though.
> So you're basically allowing for a way to specify outputs beyond the  
> first
> output in a dag? That does make sense, and might be useful for other  
> cases to,
> perhaps?

Yes, being able to work with nodes with multiple results with tablegen
patterns would be useful for a variety of things.

>
>
> I won't be able to implement this, however, since I'm only  
> prototyping just
> yet...
>
>
>> An alternative that's a bit less ambitious would be to have
>> tablegen search the output pattern for nodes which are declared
>> to support chain operands/results, and if it finds exactly one
>> such node, use that node to hook up all the chain
>> operands/results. If it finds more than one, it could issue
>> an error. This would probably be simpler and less invasive,
>> and probably enough for your specific example, though it
>> wouldn't be as general-purpose.
> Currently, I think that  the code supports having multiple nodes  
> with chain
> just fine (when I hook up a pattern to my RD instruction, I get an  
> Emit
> function that hooks up the chain to both RD and MOVE. I think it  
> might even
> join the two output chains together, not exactly sure about that.  
> Not sure if
> this is really what I want, but it would work.

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.

Dan