[PATCH] D89449: [RISCV] Initial infrastructure for code generation of the RISC-V V-extension
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 24 11:09:29 PST 2020
craig.topper added inline comments.
Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:131
+ addRegisterClass(RISCVVMVTs::vfloat64m1_t, &RISCV::VRRegClass);
+ addRegisterClass(RISCVVMVTs::vfloat64m2_t, &RISCV::VRM2RegClass);
> 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.
Profiles supporting 16-bit half-precision floating-point values will also have to implement scalar half-precision floating-point support in the f registers.
CHANGES SINCE LAST ACTION
More information about the llvm-commits