Jonas Paulsson via llvm-dev
2020-Feb-22 23:44 UTC
[llvm-dev] COPYs between register classes
Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is GRX32, which also contains the high 32-bit part registers. I have tried to find a simple way to constrain the register class of such copies (also at -O0), but this turned out to not be quite simple. Just selecting a pseudo instruction with a custom inserter does not seem to work since CopyToReg/CopyFromReg have special handlings in InstrEmitter. I then tried in SystemZDAGToDAG.cpp to select a CopyToReg to (CopyToReg COPY_TO_REGCLASS), which worked fine. But I could not get the same results with CopyFromReg. (COPY_TO_REGCLASS CopyFromReg) only resulted in a later COPY into GR32, but the COPY from the Access register was still first made to GRX32. One alternative might be to let InstrEmitter deduce the needed register class for a CopyFromReg if there is only one user which is a COPY_TO_REGCLASS. I thought this seemed a bit messy, so I instead tried adding a new TargetRegisterInfo hook that is used in InstrEmitter when emitting CopyToReg/CopyFromReg nodes (https://reviews.llvm.org/D75014). Does this make sense, or is there a better way? A related question is if the target is required to be able to implement *any* move between register classes? Thanks, Jonas
Could you emit a target specific ISD opcode where the CopyToReg is created? Then you could isel that ISD opcode however you want. ~Craig On Sat, Feb 22, 2020 at 3:45 PM Jonas Paulsson via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > On SystemZ there are a set of "access registers" that can be copied in > and out of 32-bit GPRs with special instructions. These instructions can > only perform the copy using low 32-bit parts of the 64-bit GPRs. As > reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, > this is currently broken due to the fact that the default register class > for 32-bit integers is GRX32, which also contains the high 32-bit part > registers. > > I have tried to find a simple way to constrain the register class of > such copies (also at -O0), but this turned out to not be quite simple. > Just selecting a pseudo instruction with a custom inserter does not seem > to work since CopyToReg/CopyFromReg have special handlings in InstrEmitter. > > I then tried in SystemZDAGToDAG.cpp to select a CopyToReg to (CopyToReg > COPY_TO_REGCLASS), which worked fine. But I could not get the same > results with CopyFromReg. (COPY_TO_REGCLASS CopyFromReg) only resulted > in a later COPY into GR32, but the COPY from the Access register was > still first made to GRX32. > > One alternative might be to let InstrEmitter deduce the needed register > class for a CopyFromReg if there is only one user which is a > COPY_TO_REGCLASS. I thought this seemed a bit messy, so I instead tried > adding a new TargetRegisterInfo hook that is used in InstrEmitter when > emitting CopyToReg/CopyFromReg nodes (https://reviews.llvm.org/D75014). > > Does this make sense, or is there a better way? > > A related question is if the target is required to be able to implement > *any* move between register classes? > > Thanks, > > Jonas > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200222/62f79b3c/attachment.html>
Jonas Paulsson via llvm-dev
2020-Feb-24 22:45 UTC
[llvm-dev] COPYs between register classes
On 2020-02-22 16:14, Craig Topper wrote:> Could you emit a target specific ISD opcode where the CopyToReg is > created? Then you could isel that ISD opcode however you want. >That doesn't seem quite satisfactory to me, since a copy could potentially be created in many different places. Since reg copies are kept as a general COPY instruction all the way until after regalloc until the target is supposed to implement them, it seems reasonable to let the target provide a constrained regclass at some point if needed. Adding a new TRI hook for this is one way, another one might be to view this as an isel finalization step and let the target also handle COPY instructions in FinalizeISel. It would simply be a matter then of constraining the register class. It seems possible (but ugly) though to handle this with a backend hack, by using a target pseudo opcode that needs the constrained regclass and insert that as a user of the copyFromReg during instruction selection. That might be fine if there really is only this one single case of this problem, but that would surprise me. To give some more context, here is one test case I am looking at: define i32 @fun() { %val = call i32 asm "blah", "={a0}, {a1}" (i32 0) ret i32 %val } (llc -mtriple=s390x-linux-gnu -mcpu=z196 -O0) # *** IR Dump After Finalize ISel and expand pseudo-instructions ***: # Machine code for function fun: IsSSA, TracksLiveness bb.0 (%ir-block.0): %0:grx32bit = LHIMux 0 $a1 = COPY %0:grx32bit INLINEASM &blah [attdialect], $0:[regdef], implicit-def $a0, $1:[reguse], $a1 %1:grx32bit = COPY $a0 $r2l = COPY %1:grx32bit Return implicit $r2l ISel here produces COPYs to/from the GRX32 registers (both low and high parts) where access registers a1/a0 are involved. This is then the problem since these COPYs can only be made with low-parts by the processor. This was the SelectionDAG: SelectionDAG has 15 nodes: t0: ch = EntryToken t8: ch,glue = CopyToReg t0, Register:i32 $a1, Constant:i32<0> t11: i32,ch,glue = CopyFromReg t15, Register:i32 $a0, t15:1 t13: ch,glue = CopyToReg t0, Register:i32 $r2l, t11 t15: ch,glue = inlineasm t8, TargetExternalSymbol:i64'blah', MDNode:ch<null>, TargetConstant:i64<0>, TargetConstant:i32<10>, Register:i32 $a0, TargetConstant:i32<9>,\ Register:i32 $a1, t8:1 t14: ch = Return Register:i32 $r2l, t13, t13:1 I can't simply select t8 here into a SAR (Set Access Register), because that would not provide the specific destination reg ($a1). So I tried replacing t8 with a target pseudo machine instruction opcode (CopyToAR) that looks identical on the DAG: => patched => SelectionDAG has 15 nodes: t0: ch = EntryToken t8: ch,glue = CopyToAR Register:i32 $a1, Constant:i32<0>, t0 t11: i32,ch,glue = CopyFromReg t15, Register:i32 $a0, t15:1 t13: ch,glue = CopyToReg t0, Register:i32 $r2l, t11 t15: ch,glue = inlineasm t8, TargetExternalSymbol:i64'blah', MDNode:ch<null>, TargetConstant:i64<0>, TargetConstant:i32<10>, Register:i32 $a0, TargetConstant:i32<9>,\ Register:i32 $a1, t8:1 t14: ch = Return Register:i32 $r2l, t13, t13:1 When instruction selection ends, the only difference between the DAGs is that the CopyToReg has changed opcode to the target pseudo instruction opcode CopyToAR. The idea was to then insert CopyToAR with a custom inserter. However, before that can happen InstrEmitter triggers an assert in EmitMachineNode in the "Scan the glue chain for any used physregs" clause. Here, the glue users are looped over and while a ISD::CopyToReg would simply be skipped, the target CopyToAR opcode is not. In this example, CopyToAR is glued to an inlineasm and therefore the call to F->getMachineOpcode() triggers the assert "Not a MachineInstr opcode!". I did not yet try to do the same opcode replacement for ISD::CopyFromReg since at this point it was clear to me that these nodes have special handlings in InstrEmitter and it probably would be worrisome to have a target opcode that did *not* get the same treatment even if that would succeed. My patch at https://reviews.llvm.org/D75014 now has two separate versions ("Diff 1" and "Diff 2") where the first one handles this in common code and the other one in the backend. Any comments and suggestions welcome! /Jonas> ~Craig > > > On Sat, Feb 22, 2020 at 3:45 PM Jonas Paulsson via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi, > > On SystemZ there are a set of "access registers" that can be > copied in > and out of 32-bit GPRs with special instructions. These > instructions can > only perform the copy using low 32-bit parts of the 64-bit GPRs. As > reported and discussed at > https://bugs.llvm.org/show_bug.cgi?id=44254, > this is currently broken due to the fact that the default register > class > for 32-bit integers is GRX32, which also contains the high 32-bit > part > registers. > > I have tried to find a simple way to constrain the register class of > such copies (also at -O0), but this turned out to not be quite > simple. > Just selecting a pseudo instruction with a custom inserter does > not seem > to work since CopyToReg/CopyFromReg have special handlings in > InstrEmitter. > > I then tried in SystemZDAGToDAG.cpp to select a CopyToReg to > (CopyToReg > COPY_TO_REGCLASS), which worked fine. But I could not get the same > results with CopyFromReg. (COPY_TO_REGCLASS CopyFromReg) only > resulted > in a later COPY into GR32, but the COPY from the Access register was > still first made to GRX32. > > One alternative might be to let InstrEmitter deduce the needed > register > class for a CopyFromReg if there is only one user which is a > COPY_TO_REGCLASS. I thought this seemed a bit messy, so I instead > tried > adding a new TargetRegisterInfo hook that is used in InstrEmitter > when > emitting CopyToReg/CopyFromReg nodes > (https://reviews.llvm.org/D75014). > > Does this make sense, or is there a better way? > > A related question is if the target is required to be able to > implement > *any* move between register classes? > > Thanks, > > Jonas > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200224/d2035992/attachment.html>