> On Wed, Aug 28, 2024 at 3:21 PM Robin Dapp <rdapp....@gmail.com> wrote: > > > > > Hmm - but how can you call this ambiguous? VLEN and LMUL is a runtime > > > property(?), so unknown to the compiler(?) - as you do below the only > > > way to code generate would be a agnostic way such as with a slide-down. > > > But can't you always to this, for all subregs of this sort (even with > > > offset)? > > > > LMUL (register group size) is a compile-time constant while VLEN is not. > > Hmm, but LMUL is not reflected in the assembly? Or at least it doesn't > affect register allocation?
It is set via vsetvl and considered in register allocation by "alignment", i.e. we only use register numbers % LMUL == 0. > > Once we have VLS modes that span more than the minimum runtime size of > > a vector it's ambiguous whether the mode occupies two minimum-size vectors > > or one dynamically larger one. > > But V4DF with LMUL == 2 has to always span two registers? Or is the HW > free to use a single VLA register for it? What's the use of LMUL then? Our (RISC-V) VLA modes have an encoded LMUL but the VLS ones don't. We actually disable all VLS modes that are unordered with respect to (minimum vector length * LMUL). In light of this issue I was pondering using just the minimum vector length instead and disabling everything. > Yes, as far as I can see LMUL becomes part of the unknown VLEN, > so you have to operate on VLS modes like on VLA modes iff LMUL != 1 Yes, that's also what I was hinting at in the thread (you weren't CC'd there) of a former try where I set REGMODE_NATURAL_SIZE to a "VLA number". That immediately broke a lot of tests and I didn't investigate further. Right now I hope we do operate on them the way you say but there will be oversights. There's probably no comprehensive method of making sure? Or do you have a specific knob in mind? -- Regards Robin
