Selecting "undisturbed" versus "zeroing" behavior for vector inactive and tail elements

For machines without vector register renaming, leaving elements undisturbed is the simplest approach. Writes to the elements can be masked off in hardware leaving the original values in place.

For machines with vector register renaming, a new physical destination vector register is allocated for each result vector, and so undisturbed values must be copied from the original physical register to the new physical destination register. This requires use of an additional read port to obtain the original values.

In addition, implementing undisturbed elements can add a RAW hazard between the original destination register contents and the new instruction that could reduce performance.

For purely spatial machines with register renaming, undisturbed tail elements would not add additional execution cycles, as all tail elements are written on same cycle as other elements, though there is some additional power to read old values.

For longer temporal vector registers with renaming, additional cycles are required to read out old tail elements to copy to the tail of the new destination physical register.

However, we can assume renamed vector machines have to rename the individual vector registers in a vector register group, so large LMUL values do not further increase the penalty of undisturbed tail elements.

It is further possible to divide longer vector registers into smaller sub-registers that are renamed independently to reduce the performance penalty for copying the tail elements. However, this will rapidly increase the cost of renaming tables.

An assumption is that most OoO machines with renaming will not have very deep temporal vector registers, as OoO execution and renaming will reduce the incentive for longer temporal vector registers.

Some other OoO machines with long temporal vector registers may implement an in-order vector unit, with a separate load-data queue to support decoupled and out-of-order memory accesses. Undisturbed elements would then be handled as in any vector unit without renaming.

Zeroing inactive and tail elements complicates in-order implementations without register renaming.

While the simplest implementations could explicitly write zeros to the affected destination elements, this would cause every vector instruction to have an occupancy proportional to the maximum vector length. This is particularly problematic for large LMUL values where up to a quarter of the entire vector regfile would have to be written.

Optimized non-renamed systems will use a microarchitectural zero bit attached to each element group, where an element group is the atomic unit of microarchitectural vector execution, which is often equal to the spatial datapath width.

The zero bit indicate that the corresponding element group is all zero. On dispatch to a vector functional unit, this bit vector must be snapshot and dispatched to the vector functional unit along with the vector instruction so that the read ports can multiplex zeros in place of source operands if the zeroed element groups are read. Also, writes to an element group with the zero bit set, must mux in zero to the write port for inactive and tail elements, and then reset the zero bit.

After dispatch, the decode stage bit vector must be updated with the element groups that will be zeroed (e.g., for shorter vl), to allow a following instruction to be dispatched with the updated bit vector.

Out-of-order vector machines with spatial vector registers can directly write zero to the inactive and tail elements in the new physical destination register. With larger LMUL, entire vector registers at the tail of a result can be renamed to a single constant-zero register to save physical register storage and to reduce execution effort.

For renamed vector machines with temporal vector registers, a scheme similar to that for in-order vectors can be used with microarchitectural zero bits on each element group, except writes are simpler as all elements are written with new values.