[PATCH] D118302: [Spill2Reg] Code generation part 2.

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 4 07:10:43 PST 2022


arsenm added inline comments.


================
Comment at: llvm/lib/CodeGen/Spill2Reg.cpp:248
+    MachineInstr *SpillToVector = TII->spill2RegInsertToVectorReg(
+        VectorReg, OldReg, SpillData.MemBits, StackSpill->getParent(),
+        /*InsertBeforeIt=*/StackSpill->getIterator(), TRI);
----------------
vporpo wrote:
> arsenm wrote:
> > Is this assuming you can only spill one register to one vector register? What if you can place multiple values in different subregisters?
> Yes, for now we can only spill one register to the first lane of one vector register. The reason is that if we want to spill to another lane other than the first one in x86 then we need to use the PINSR/PEXTR instructions rather than MOVD which have a higher latency and use more uops. But yeah, I think it is still worth extending it to spill to more lanes in the future.
> 
> Here is the relevant data from Agner Fog's instruction tables:
> ```
>                   uops   uops      uops
>                   fused  unfused   each   latency  throughput
>                   domain domain    port
> Spill-to-reg
> ------------
> MOVD mm/x r32/64    1     1        p5       2       1
> MOVD r32/64 mm/x    1     1        p0       2       1
> 
> PINSRD/Q x,r,i      2     2        2p5      3       2
> PEXTRB/W/D/Q r,x,i  2     2       p0 p5     3       1
> ```
The reason I ask is because I'm very interested in using something more like this for AMDGPU. We currently have 2 custom, convoluted mechanisms for handling "spills" to registers. I'm wondering if we could adapt this pass to one of them, but it would require a broader notion of how/where the registers can be spilled (and there might be some additional liveness hazards)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D118302/new/

https://reviews.llvm.org/D118302



More information about the llvm-commits mailing list