[PATCH] D93750: [RISCV] Frame handling for RISC-V V extension.

Wed Jan 6 04:30:23 PST 2021

HsiangKai added inline comments.

================
Comment at: llvm/include/llvm/CodeGen/MachineFrameInfo.h:226
+  /// vector objects have been allocated yet.
+  bool HasScalableVectorObjects = false;
+
----------------
jrtc27 wrote:
> HsiangKai wrote:
> > HsiangKai wrote:
> > > jrtc27 wrote:
> > > > How come SVE doesn't need this already?
> > > I didn't dig into how SVE implements it. I will do some study.
> > The SVE spill/fill instructions have VL-scaled addressing modes such as:
> > ldr z8, [fp, #-7 mul vl]
> > 
> > In SVE, there is no need to do address calculation to get the location of SVE frame objects. The number of SVE objects is encoded in the instruction.
> > 
> > In RVV, we have no VL-scaled addressing mode. We need to read out VLENB, do multiplication or shift to know the size of RVV objects, and add/subtract the accumulated size from FP/SP. To avoid the repeated address calculation, we have two areas for RVV objects in the frame. One is for RVV object addresses, and another is for RVV objects themselves. SP will be updated by the size of RVV object region if there are any RVV objects. We still could use SP to access frame objects, but it will need to add multiple of the run-time VLENB value. To ease the complexity, we use FP to access frame objects if there is any RVV object on the stack. That’s why I define hasScalableVectorObjects() to know about it.
> Isn't that basically just a special case of DYNAMIC_STACKALLOC? Can we not reuse some of that logic with BP?
It is not a special case of DYNAMIC_STACKALLOC. The RVV objects are statically allocated. The path is different in SelectionDAGBuilder::visitAlloca().

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93750