[llvm-dev] Opcodes with 32-bit pair vs 64-bit register
Dvir Yitzchaki via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 22 01:08:47 PST 2018
Have you tried working with AltOrders (see Target.td)?
It seems suitable for your needs.
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?
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
<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,
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<>; def R1 : Core<1, "%r1">, DwarfRegNum<>; def R2 : Core<2, "%r2">, DwarfRegNum<>; def R3 : Core<3, "%r3">, DwarfRegNum<>; def R0R1 : CorePair<0,"%r0",[R0,R1] >; def R2R3 : CorePair<2,"%r2",[R2,R3] >; def R0_64 : Core64<0, "%r0", [R0]>, DwarfRegNum<>; def R1_64 : Core64<1, "%r1", [R1]>, DwarfRegNum<>;
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...
More information about the llvm-dev