[PATCH] D112408: [RISCV] Add the zve extension according to the v1.0 spec

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 15 11:00:12 PST 2022


craig.topper added inline comments.


================
Comment at: clang/lib/Basic/Targets/RISCV.cpp:184
     Builder.defineMacro("__riscv_v_min_vlen", Twine(MinVLen));
+    Builder.defineMacro("__riscv_v_max_eew", Twine(MaxEew));
+    Builder.defineMacro("__riscv_v_max_eew_fp", Twine(MaxEewFp));
----------------
eopXD wrote:
> craig.topper wrote:
> > khchen wrote:
> > > craig.topper wrote:
> > > > Would't ELEN be the correct term here? Not EEW.
> > > https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#182-zve-vector-extensions-for-embedded-processors shows zve* extensions have `Supported EEW`, I guess it's why the term is `EEW`.
> > > 
> > > 
> > Is that because that section talks about them as a set of values rather than a single maximum?
> I think Zve is restricting the EEW, not ELEN.
The spec defines ELEN as "The maximum size in bits of a vector element that any operation can produce or consume" That sounds like maximum EEW to me.

This statement appears in section 3.4.2

"For standard vector extensions with
ELEN=32, fractional LMULs of 1/2 and 1/4 must be supported. For standard vector extensions with ELEN=64, fractional
LMULs of 1/2, 1/4, and 1/8 must be supported."

I take "standard vector extensions with ELEN=32" to mean Zve32x, Zve32f.

And "standard vector extensions with ELEN=64" to mean Zve64x, Zve64f, Zve64d, and V.

Am I interpreting that incorrectly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112408



More information about the llvm-commits mailing list