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

Fraser Cormack via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 25 04:30:00 PST 2020

frasercrmck added inline comments.

Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:131
+    addRegisterClass(RISCVVMVTs::vfloat64m1_t, &RISCV::VRRegClass);
+    addRegisterClass(RISCVVMVTs::vfloat64m2_t, &RISCV::VRM2RegClass);
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.



More information about the llvm-commits mailing list