Are the elements past vl guaranteed to survive after reconfiguration?

[jnk0le]

Regarding issues raised in #157

In current spec we have 3 possible scenarios when data is not zeroed past vl:

1. vl == 0
2. after vsetvl to a smaller length unless register is targeted as destination
3. vstart >= vl

The current spec is not clear about this matter so we are probably going to see 2 possible disciplines:

A: Simply leave it as is.
B: Zero it (probably at SLEN granurality) to eg. free up resources for other SMT threads or provide better overprovision-less renaming.

I think it falls into the concerns pointed by Andrew and also commits to potential security holes.

I talked to @kasanovic about this today, and he said the TG's principal concern was about software inadvertently relying on the implementation's behavior. In particular: zero-past-VL and preserve-past-VL are both useful behaviors in some situations, and it's easy to imagine a software developer accidentally relying on whichever one the development machine provides. So we could end up in the situation where software runs only under one discipline or the other, risking the possibility of the adoption of a de-facto standard.

[hanna-kruppe]

I'm not sure I understand what you mean by "reconfiguration" in the title (writes to vtype? those don't have any effect on their own if no further vector instructions are executed). But

• the spec explicitly states (in §3.3) that for vstart >= vl (including when vl == 0) the destination register is not updated at all
• source registers are, of course, not to be modified by instructions that aren't explicitly noted to be destructive (which can also be viewed as having one register number in the encoding specify both a source and a destination)

So the answer is clearly "leave it as is" in all three cases you mention.

We could add a note making the second point explicit, it probably just didn't occur to anyone before.

[jnk0le]

I meant the use-case when one is going to rely on the content of elements that were temporarily past vl but not zeroed/destroyed as a destination group.

in this case:

li a0, 8
li a1, 4
vsetvli x0, a0, e8
vle.v v0, (a4)    
vle.v v1, (a5)    

vsetvli x0, a1, e8
vle.v v2, (a6) # or just absolutely anything not touching v0, v1

vsetvli x0, a0, e8
vadd.vv v3, v0, v1

is the upper part of v3 guaranteed (or not) to be correct on any possible architecture?

[hanna-kruppe]

Thanks for the example. Yes, for reasons outlined in my previous comment, the result must be that elements 4...7 of v3 are the sums of the corresponding bytes loaded from (a4) and (a5) at the beginning. I do not see how anything else could be justified from the text of the spec, and clearly we don't want to allow implementations to vary on this (cf. Andrew's comment you quoted).

[jnk0le]

I think it needs an explicit note unlil #157 is resolved, since knowing "zero past vl" rule that slightly favours renamed architectures, it is counter intuitive to rely on such elements.

[kasanovic]

The general policy in the spec is to assume nothing is modified in machine state unless explicitly listed in an instruction's definition. Adding notes that an instruction doesn't affect some state would require we went through and did this for every instruction that didn't modify other registers, otherwise we'd have consistency complaints. i.e., adding an explicit note here would cause more confusion than it would remove.