[PATCH] D89449: [RISCV] Initial infrastructure for code generation of the RISC-V V-extension

[Evandro Menezes via Phabricator via llvm-commits]

evandro added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:131
+
+    addRegisterClass(RISCVVMVTs::vfloat64m1_t, &RISCV::VRRegClass);
+    addRegisterClass(RISCVVMVTs::vfloat64m2_t, &RISCV::VRM2RegClass);
----------------
frasercrmck wrote:
> evandro wrote:
> > craig.topper wrote:
> > > evandro wrote:
> > > > jrtc27 wrote:
> > > > > HsiangKai wrote:
> > > > > > craig.topper wrote:
> > > > > > > Should the types be qualified with hasStdExtD()?  I have the same question for F but it looks like V extension currently implicitly enables the F extension.
> > > > > > I am curious about V should imply F or not. It is vague in the V specification.
> > > > > Currently I read it as no, in that V+Zfinx is a valid combination and would have the FP vector-scalar instructions reading the FP scalar from the "integer' register file.
> > > > V does not imply Zfh, F, D or Zfinx.  However, V supports `half`, `float` and `double` types regardless of F or D or Zfinx.  The V instructions which specify scalar `half`, `float` or `double` operands do require the respective extensions.  At least as I read the spec.  
> > > This doesn't sound like it is just talking about the scalar operands, but maybe I'm reading it wrong.
> > > 
> > > ```
> > > Vector floating-point instructions require the presence of base scalar floating-point extensions corresponding to the supported vector floating-point element widths.
> > > 
> > > Note
> > > Profiles supporting 16-bit half-precision floating-point values will also have to implement scalar half-precision floating-point support in the f registers.
> > > ```
> > Indeed.  Now I wonder about the integer instructions if they have requirements on XLEN to support the corresponding integer SEWs.
> In section 3.3.1, we have this:
> 
> ```
> In the base vector "V" extension, only SEW up to ELEN = max(XLEN,FLEN) are required to be supported. Other platforms may impose different constraints on ELEN
> ```
> 
> So I wouldn't say it's required. We can have e64 on RV32, for instance. And at least for the integer scalar move instructions (17.1) it accounts for `SEW > XLEN`:
> 
> ```
> The vmv.x.s instruction copies a single SEW-wide element from index 0 of the source vector register to a destination integer register. If SEW > XLEN, the least-significant XLEN bits are transferred and the upper SEW-XLEN bits are ignored. If SEW < XLEN, the value is sign-extended to XLEN bits.
> ```
> 
> I haven't thought through the implications for SEW > XLEN on code generation but it might trip us up if we're not careful.
I asked Andrew Waterman and his answer is, in English, that:

> The data types fully supported in V, for both scalar and vector operations, mirror those supported by the base ISA.  For example, RV32IMCFV, only SEW up to 32, for both integer and FP, both scalar and vector operations; RV32IMCFDV, only SEW up to 32, both scalar and vector, integer operations and SEW up to 64, both scalar and vector, FP operations.






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89449