llvm dev - Jan 2016 - Using `smullohi` in TableGen patterns

> As far as I know, you cannot define a tablegen pattern with multiple
results, and need to use C++ matching. I’m kind of surprised there are
defined td nodes for these.

Yes they were added a while ago, but never used.

If I write a C++ matcher, will the register allocator work correctly? The
multiplication instruction I'm working with always writes the result to
registers `R1` and `R0`, but if that logic is in C++, how will the
regallocator know?

On Mon, Jan 18, 2016 at 11:34 PM, Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
> On Jan 17, 2016, at 22:41, Dylan McKay via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I’m hitting TableGen errors trying to match the smullohi <lhs>
<rhs> node
> in TableGen.
>
> smullohi returns two results, which is the problem. I am not sure how to
> match against multiple results. The only other nodes to return two operands
> are umullohi, udivrem, and sdivrem. There are no examples of these in
> TableGen in tree.
>
> The closest I can get is this:
>
>         set (R1, R0, (umullohi GPR8:$lhs, GPR8:$rhs))
>
>
> As far as I know, you cannot define a tablegen pattern with multiple
> results, and need to use C++ matching. I’m kind of surprised there are
> defined td nodes for these.
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160118/0abcc70c/attachment.html>

> On Jan 18, 2016, at 02:48, Dylan McKay <dylanmckay34 at gmail.com>
wrote:
> 
> > As far as I know, you cannot define a tablegen pattern with multiple
results, and need to use C++ matching. I’m kind of surprised there are defined
td nodes for these.
> 
> Yes they were added a while ago, but never used.
I vaguely remember some patches to add support for multiple results, but I’m not
sure this was ever finished.
> 
> If I write a C++ matcher, will the register allocator work correctly? The
multiplication instruction I'm working with always writes the result to
registers `R1` and `R0`, but if that logic is in C++, how will the regallocator
know?
The pattern isn’t really related to the machine instruction’s operand
definition. The multiple operands will each be defs.

-Matt

-
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160118/61242442/attachment.html>

> If I write a C++ matcher, will the register allocator work correctly? The
> multiplication instruction I'm working with always writes the result to
> registers `R1` and `R0`, but if that logic is in C++, how will the
> regallocator know?
You'd add extra CopyFromReg nodes, glued[1] to your multiplication
node. The values produced by the CopyFromReg nodes are what other
users should actually be using[2]. x86 has similar hard-coded
registers on its multiplication operations, I believe. Try "llc
-view-sched-dags ..." to see the kind of thing you should be
producing.

Cheers.

Tim.

[1] Glue is represented by producing/consuming a value of type MVT::Glue.
[2] You may well have to manually call ReplaceAllUsesOfValueWith after
creating them to make that happen.

> You'd add extra CopyFromReg nodes, glued[1] to your multiplication node
Thanks makes a lot of sense, thanks Tim!

On Wed, Jan 20, 2016 at 4:45 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> > If I write a C++ matcher, will the register allocator work correctly?
The
> > multiplication instruction I'm working with always writes the
result to
> > registers `R1` and `R0`, but if that logic is in C++, how will the
> > regallocator know?
>
> You'd add extra CopyFromReg nodes, glued[1] to your multiplication
> node. The values produced by the CopyFromReg nodes are what other
> users should actually be using[2]. x86 has similar hard-coded
> registers on its multiplication operations, I believe. Try "llc
> -view-sched-dags ..." to see the kind of thing you should be
> producing.
>
> Cheers.
>
> Tim.
>
> [1] Glue is represented by producing/consuming a value of type MVT::Glue.
> [2] You may well have to manually call ReplaceAllUsesOfValueWith after
> creating them to make that happen.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160120/4e40ae31/attachment-0001.html>