Page MenuHomePhabricator

[TableGen] Support tied operands that are both source operands
Needs ReviewPublic

Authored by bleibig on Aug 25 2020, 6:27 PM.

Details

Summary

Currently tied operands have a restriction that one is a source and
the other is a dest. This patch aims to relax that restriction, so
that two source operands can be tied.

The purpose is enable the kind of tablegen definition described here:
http://lists.llvm.org/pipermail/llvm-dev/2019-April/131663.html
Where two source operands from different register files must have the
same register number, as the bits in the encoding specify the register
number for two different operands (other bits specify the register
files used). Even though the first operand is called "dst", it must be
treated as a source operand as it holds an address that the
instruction writes to (like a store instruction), and thus must be
loaded appropriately before the instruction is generated.

Part of these changes remove the ConstraintChecking{4,5}.td tests as
they check for an error that shouldn't be occuring anymore, tests 6
and 7 have been shifted down to replace them.

Diff Detail

Event Timeline

bleibig created this revision.Aug 25 2020, 6:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 25 2020, 6:27 PM
bleibig requested review of this revision.Aug 25 2020, 6:27 PM

I'm not sure why the checks were initially added, whether it is because the tied operand system is designed only for use and def tied operands and won't work in any other way without major changes, or just because there hasn't been a use case yet for two tied source operands. Either way, I feel the changes I have so far may be insufficient to solve this, so any feedback for further changes would be greatly appreciated.

bjope added a subscriber: bjope.Sep 1 2020, 1:00 AM
bjope added a comment.Sep 1 2020, 2:00 AM

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?

I mean, the main 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.

I'm also worried about that there is not test case for the changes in the backend (TwoAddressIntructionPass and how this impacts the rest of codegen - can't see anything that verifies that this patch actually ties the virtual registers together).

Following up on this, I've realized that these changes might not be necessary for what I am trying to do, as it seems like I can make things work without using the constraint at all. This can be de-prioritized for the time being.