[libre-riscv-dev] SV Prefix questions

[Jacob Lifshay]

On Tue, Jun 25, 2019 at 10:44 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> On Wed, Jun 26, 2019 at 6:27 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> > Starting from the V extension spec:
> > https://github.com/riscv/riscv-v-spec/blob/e014590220e7b95b1dfa3c0665277ae1550828c9/v-spec.adoc#vsetvlivsetvl-instructions
>
>  "The vl setting rules are designed to be sufficiently strict to
> preserve vl behavior across register spills and context swaps for AVL
> ≤ VLMAX, yet flexible enough to enable implementations to improve
> vector lane utilization for AVL > VLMAX.
>
> For example, this permits an implementation to set vl = ceil(AVL / 2)
> for VLMAX < AVL < 2*VLMAX in order to evenly distribute work over the
> last two iterations of a stripmine loop. Requirement 2 ensures that
> the first stripmine iteration of reduction loops uses the largest
> vector length of all iterations, even in the case of AVL < 2*VLMAX.
> This allows software to avoid needing to explicitly calculate a
> running maximum of vector lengths observed during a stripmined loop.
> "
>
> those are *implementation* details.  they're bleeding *implementation*
> details - hard-coding the assumption that implementors will be doing
> SIMD "Lanes" - into the *specification*.
supporting SIMD lanes is not the only reason: having the last 2
iterations split approximately in half helps when doing reduction,
since a binary tree reduction is more parallelizable than any other
sort.

>
> that is not an appropriate thing to do, and we should not be following
> their flawed approach.
>
> we are *not* doing a "Lanes" (SIMD) specification.  SV sits on top of
> the *scalar* register file, not on top of vector *lanes*.
changing the spec in a way that benefits lanes without detracting from
processors that use multiple scalar ops -- I would think that's a good
thing, not something to avoid.