llvm dev - Aug 2020 - Relaxing the restrictions on Machine instruction tied operands

Hello,

One of the operand constraints that Tablegen and Machine instrs can impose is
tied operands, which means that a def and use in the same instruction must be
the same physical register. This allows an operand to be accounted for even if
it is not explicitly encoded in the instruction. I am looking at loosening the
constraint in a couple ways: having both operands be use (source) operands, and
enabling the tied registers to be in different register classes but having the
same register number. This is for a target I am writing a backend for, where
these registers are pointing to memory, and the instructions using them are
transparently performing loads and stores, rather than having the contents of
the registers read and written to.

A colleague of mine inquired about such functionality a while ago
(http://lists.llvm.org/pipermail/llvm-dev/2019-April/131663.html), and I’ve made
some initial steps at implementing this with the patch here:
https://reviews.llvm.org/D86586. I will greatly appreciate any feedback or
advice on how to implement this, and what in LLVM will need to change in order
for this to work.

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200831/b7108817/attachment.html>

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Brian
Leibig via llvm-dev
Sent: den 31 augusti 2020 23:02
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Relaxing the restrictions on Machine instruction tied
operands

Hello,

One of the operand constraints that Tablegen and Machine instrs can impose is
tied operands, which means that a def and use in the same instruction must be
the same physical register. This allows an operand to be accounted for even if
it is not explicitly encoded in the instruction. I am looking at loosening the
constraint in a couple ways: having both operands be use (source) operands, and
enabling the tied registers to be in different register classes but having the
same register number. This is for a target I am writing a backend for, where
these registers are pointing to memory, and the instructions using them are
transparently performing loads and stores, rather than having the contents of
the registers read and written to.

A colleague of mine inquired about such functionality a while ago
(http://lists.llvm.org/pipermail/llvm-dev/2019-April/131663.html<https://protect2.fireeye.com/v1/url?k=a435fe92-fa9544fc-a435be09-861d41abace8-69a4b9f5cd618bdd&q=1&e=0e0b79c1-dd48-4c3d-9b6f-823bfe087c52&u=http%3A%2F%2Flists.llvm.org%2Fpipermail%2Fllvm-dev%2F2019-April%2F131663.html>),
and I’ve made some initial steps at implementing this with the patch here:
https://reviews.llvm.org/D86586<https://protect2.fireeye.com/v1/url?k=00f60dce-5e56b7a0-00f64d55-861d41abace8-2167be3bcfef1803&q=1&e=0e0b79c1-dd48-4c3d-9b6f-823bfe087c52&u=https%3A%2F%2Freviews.llvm.org%2FD86586>.
I will greatly appreciate any feedback or advice on how to implement this, and
what in LLVM will need to change in order for this to work.

Thanks,
Brian

(I happened to write something in the D86586 review, but maybe I should add it
here in llvm-dev as well for completeness)


I don't really understand the problem situation. Why are you having two
source operands if they need to be the same? Can't you ensure that by only
having one source operand?

The reason for having tied operands today is to be able to model two address
instructions while having SSA form. When we must have different virtual
registers as src and dst. SSA deconstruction, to be more specific the
TwoAddressInstructionPass, will tie the register together to get the single
virtual register when SSA form isn't needed any longer. In your case, you
only deal with source operands, so there is no problem with SSA form. You can
either model your instructions as having a single source, or just use the same
virtual register in multiple source operands.
Got a feeling that you are trying to misuse the tied-operand concept here
somehow. And I could not see anything in the suggested patch that actually tied
the source operands together (in the backend).

Regards,
Björn


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