[PATCH] D124869: [RISCV] Hoist VSETVLI out of idiomatic fixed length vector loops
Philip Reames via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue May 24 13:03:34 PDT 2022
reames added inline comments.
================
Comment at: llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp:1293
+
+ if (RISCVII::LMUL_1 != Info.getVLMUL())
+ return false;
----------------
craig.topper wrote:
> What prevents supporting other LMULs?
Nothing, we just need to adjust the formula below for it. Mind if I do this in a separate change? I'm still not 100% trusting my mental model of L:MUL, and would prefer to have that reviewed on its own.
I will add a TODO.
================
Comment at: llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp:105
+
+ uint8_t getSEW() const { return SEW; }
+ RISCVII::VLMUL getVLMUL() const { return VLMul; }
----------------
craig.topper wrote:
> reames wrote:
> > craig.topper wrote:
> > > Any reason to restrict this uint8_t? Looks like it's a assigned to unsigned where it's used.
> > uint8_t matches the actual type of the field. I can change it if you want, but it seems cleaner to me to match the field type.
> I was thinking of the uint8_t as an implementation choice I made to keep the data structure size down. It could have been a 7 bit bitfield or stored in log2 form. It would also need to change if SEW=256, 512, or 1024 came back to life.
>
> That was just my thinking. If you want to keep it as uint8_t it's fine with me.
I see your point, could go either way. I think either answer is reasonable here.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124869/new/
https://reviews.llvm.org/D124869
More information about the llvm-commits
mailing list