[llvm-dev] Opcodes with 32-bit pair vs 64-bit register

[Dvir Yitzchaki via llvm-dev]

Have you tried working with AltOrders (see Target.td)?
It seems suitable for your needs.

Regards,
Dvir

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Davis, Alan via llvm-dev
Sent: Wednesday, January 17, 2018 22:31
To: llvm-dev at lists.llvm.org
Subject: [Digital Signature Failure] [llvm-dev] Opcodes with 32-bit pair vs 64-bit register

Mark, did you get anywhere with this? We have a similar issue, where a family of otherwise-identical instructions operates on different register classes depending on a non-static property -- functional unit selection in our case.

I started to head down the path of using multidefs but quickly abandoned that. I had envisioned a MachineOperand that would hold the functional unit assignment, and having a pass that used that to set up register constraints rather than getting them from the static tables.

For your case, can you not simply define the two 32-bit halves as subregisters of the 64-bit class?

-Alan

From: Mark Schimmel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
To: "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
Subject: [llvm-dev] Opcodes with 32-bit pair vs 64-bit register
                operands
Message-ID:
                <549704409B55EF4EA338DE0614245F4401575B233E at us01wembx1.internal.synopsys.com<mailto:549704409B55EF4EA338DE0614245F4401575B233E at us01wembx1.internal.synopsys.com>>

Content-Type: text/plain; charset="utf-8"

Can anyone suggest how to define an opcode that takes a pair of registers on a 32-bit architecture but a single 64-bit wide register on a 64-bit architecture? For example, the following instruction converts a double to a single. The source operand is a register of class "Pair64". Is there a way to define it such that the register class is defined at runtime when we know if it should be a 64-bit register class?
def FD2S_rr: RRX<0b00110,0,0,0, (outs Core32:$a), (ins Pair64:$b),
               "FD2S\t$a,$b"),[(set f32:$a, (fpround f64:$b))]>; Example register classes:
def Core32: RegisterClass<"XYZ", [i32,f32], 32,
               (add R0,R1,R2,R3,...
def Pair64: RegisterClass<"XYZ", [i64,f64], 64,...
               (add R0R1, R2R3,...
def WideCore : RegisterClass<"XYZ", [i64,f64], 64,
               (add R0_64, R1_64 ...

def R0 : Core<0, "%r0">, DwarfRegNum<[0]>; def R1 : Core<1, "%r1">, DwarfRegNum<[1]>; def R2 : Core<2, "%r2">, DwarfRegNum<[2]>; def R3 : Core<3, "%r3">, DwarfRegNum<[3]>; def R0R1 : CorePair<0,"%r0",[R0,R1] >; def R2R3 : CorePair<2,"%r2",[R2,R3] >; def R0_64 : Core64<0, "%r0", [R0]>, DwarfRegNum<[0]>; def R1_64 : Core64<1, "%r1", [R1]>, DwarfRegNum<[1]>;

As I understand it, tablegen emits static tables with hard references to register classes and such. I fear that I'll need to duplicate all the opcodes that have Pair64 operands and define identical ones with WideCore operands. I can imagine changing the tablegen backend to emit tables with dynamic initializers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180122/6c24f239/attachment-0001.html>