[llvm-dev] Relaxing the restrictions on Machine instruction tied operands

Tue Sep 1 02:10:22 PDT 2020

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>