[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

[David A. Greene via llvm-dev]

Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> writes:

> 2. I know that there has been some discussion around support for
> changing the vector length during program execution (e.g., to account
> for some (proposed?) RISC-V feature), perhaps even during the
> execution of a single function. I'm very concerned about this idea
> because it is not at all clear to me how to limit information transfer
> contaminated with the vector size from propagating between different
> regions. As a result, I'm concerned about trying to add this on later,
> and so if this is part of the plan, I think that we need to think
> through the details up front because it could have a major impact on
> the design.

Can you elaborate a bit on your concerns?  I'm not sure how allowing
vector length changes impacts the design of this proposal.  As far as I
understand things, this proposal is about dealing with unknown vector
lengths, providing types and intrinsics where needed to support
necessary operations.  It seems to me that building support for changing
the vscale at runtime is somewhat orthogonal.  That is, anyone doing
such a thing will probably have to provide some more intrinsics to
capture the dependency chains and prevent miscompilation, but the basic
types and other intrinsics would remain the same.

What I'm going to say below is from my (narrow) perspective of machines
I've worked on.  It's not meant to cover all possibilities, things
people might do with RISC-V etc.  I intend it as a (common) example for
discussion.

Changing vector length during execution of a loop (for the last
iteration, typically) is very common for architectures without
predication.  Traditional Cray processors, for example, had a vector
length register.  The compiler had to manage updates to the vl register
just like any other register and instructions used vl as an implicit
operand.

I'm not sure exactly how the SVE proposal would address this kind of
operation.  llvm.experimental.vector.vscale is a vector length read.  I
could imagine a load intrinsic that takes a vscale value as an operand,
thus connecting the vector length to the load and the transitive closure
of its uses.  I could also imagine an intrinsic to change the vscale.
The trick would be to disallow reordering vector length reads and
writes.  None of this seems to require changes to the proposed type
system, only the addition of some (target-specific?) intrinsics.

I think it would be unlikely for anyone to need to change the vector
length during evaluation of an in-register expression.  That is, vector
length changes would normally be made only at observable points in the
program (loads, stores, etc.) and probably only at certain control-flow
boundaries (loop back-edges, function calls/returns and so on).  Thus we
wouldn't need intrinsics or other new IR for every possible operation in
LLVM, only at the boundaries.

                          -David