On Fri, Dec 16, 2022 at 1:59 PM Palmer Dabbelt <pal...@dabbelt.com> wrote: > > On Fri, 16 Dec 2022 12:01:04 PST (-0800), jeffreya...@gmail.com wrote: > > > > > > On 12/14/22 04:36, juzhe.zh...@rivai.ai wrote: > >> From: Ju-Zhe Zhong <juzhe.zh...@rivai.ai> > >> > >> Since store instructions doesn't care about tail policy, we remove > >> vste from "ta" attribute. Hence, we could have more fusion chances > >> and better optimization. > >> > >> gcc/ChangeLog: > >> > >> * config/riscv/vector.md: Remove vste. > > Just to confirm that I understand the basic model. Vector stores only > > update active elements, thus they don't care about tail policy, right? > > > > Assuming that's the case, then this is OK. > > That had been my assumption as well, but I don't see that explicitly > called out in the ISA manual. I see > > Masked vector stores only update active memory elements. > > where "active" is defined as > > * The _body_ elements are those whose element index is greater than or > equal > to the initial value in the `vstart` register, and less than the current > vector length setting in `vl`. The body can be split into two disjoint > subsets: > > ** The _active_ elements during a vector instruction's execution are the > elements within the body and where the current mask is enabled at that > element > position. The active elements can raise exceptions and update the > destination > vector register group. > > but I don't see anything about the unmasked stores. The blurb about > tail elements only applies to registers groups, not memory addresses, so > I think that's kind of a grey area there too. I was pretty sure the intent > here was to have tail elements not updated in memory, so hopefully I'm just > missing something in the spec.
As discussed on the github issue, I think there is sufficient justification in the spec to say that vector stores are forbidden from accessing tail elements even if unmasked. (And of course the ISA would be pretty useless if that weren't the case...) But there's no reason not to clarify the language in the spec, so as to make it easier for readers to grok. > > I open an issue to check: https://github.com/riscv/riscv-v-spec/issues/846
