[PATCH] D95146: [RISCV] Make v extension imply zvamo, zvlsseg

Simon Cook via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 22 01:07:09 PST 2021


simoncook added a comment.

In D95146#2514390 <https://reviews.llvm.org/D95146#2514390>, @kito-cheng wrote:

> So how about GCC/binutils, GNU toolchain using a weird work-around here, `v` implied `zvamo` and `zvlsseg`, and `zvamo`/`zvlsseg`/`zvqmacc` implied `v`...

Having the implications both ways round is a bit annoying to implement this way. I can't forward declare SubtargetFeatures in TableGen, and presumably even if I could I would send the tools in an infinite loop trying to initialise things in this case, so a more detailed/careful change would be needed.

In the mean time I will park this change, and add 'v' implying its subfeatures in clang, since this would catch most cases we expect users to use (I don't think manually enabling features is a common use case). I can then later look at a more detailed/complete fix when enabling features directly with -mattr.

@kito-cheng To clarify, if someone asks for e.g -march=rv32izvamo0p9, I enable 'v' because that's implied by zvamo, do we also enable zvlsseg, or does asking just for zvamo mean 'v+zvamo' but not 'v+zvamo+zvlsseg'/do I imply these features recursively?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95146



More information about the llvm-commits mailing list