[PATCH] [Tablegen] Attempt to add support for patterns containing nodes with multiple results.

[hfinkel at anl.gov]

In http://reviews.llvm.org/D8373#142801, @tstellarAMD wrote:

> In http://reviews.llvm.org/D8373#142633, @hfinkel wrote:
>
> > In http://reviews.llvm.org/D8373#142510, @tstellarAMD wrote:
> >
> > > The second output on those R600 instructions is just there to reserve a temp register to make it easier to lower the instruction later on.  I think this patch should be OK.
> >
> >
> >
>


...

> > Craig, this is indeed a use case we need to support: having a pseudo-instruction with a 'scratch register' output definition. However, it does raise the question that, if we're going to support pattern matching instructions with multiple output operands (which is the point here), what should we do if the input pattern does not itself have multiple output operands?

> 

> 

> Hi Hal,

> 

> Do we need to support this use case because there are other targets that do this too?  Otherwise if R600 is the only target doing this, would it help if I tried to rework this pseudo to only have one output?


I am fairly certain that you're not the only target doing this. I recall doing this myself at some point (although I selected the instructions manually in *ISelDAGToDAG because I did not discover the same trick that you did). Having this supported by TableGen properly will be convenient.

> 

> 

> > In short, I don't understand your any_i1 solution. It does not help to match the type of vector_insert, etc., and SI_INDIRECT_SRC, etc. already have multiple output operands. The type of the second output operand might have an ambiguous type, but why does that matter if we're not matching against it? Forcing the user to choose a type that is sure to be ignored / irrelevant seems confusing.

> 





http://reviews.llvm.org/D8373

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/