Davis, Alan via llvm-dev
2018-Jan-17 20:30 UTC
[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>
To: "llvm-dev at lists.llvm.org" <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>
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/20180117/598c0e27/attachment.html>
Dvir Yitzchaki via llvm-dev
2018-Jan-22 09:08 UTC
[llvm-dev] Opcodes with 32-bit pair vs 64-bit register
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>