[PATCH] D32737: [Constants][SVE] Represent the runtime length of a scalable vector

Renato Golin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun May 21 04:52:13 PDT 2017


rengolin added a comment.

In https://reviews.llvm.org/D32737#760310, @sanjoy wrote:

> I've only lightly read the spec, but it looks like the vector length can be controlled by writing to the `ZCR_ELn` registers (so, e.g. user code could make a syscall to change the vector length)?


As I explained to Hal on his comment, that is correct but doesn't have the effect you're expecting.

Vectors don't have length, they have the "idea that they may have length", and it's up to the CPU to control that.

Just to be clear, the example you propose has no effect on the notion of length:

  // SVE length defined at boot time to be 4
  ...
  add z0.s, p0/m, z0.s, z1.s // z0+=z1 only where the predicate p0 is valid, which here is "up-to" 4 vector lengths
  ...
  svc ... // Try to change vector length to 8, assuming this works
  ...
  add z0.s, p0/m, z0.s, z1.s // z0+=z1 only where the predicate p0 is valid, which here is "up-to" 8 vector lengths

In the case above, the change in length applies to both z0 and z1, as well as p0 and all the other SVE vectors uniformly.

Using other SVE instructions, the predicate p0 will be built to go "up-to" the end of the array/memory as the semantics allows in IR, either compiler-constant or runtime check, so there's no compiler-generated undefined behaviour.

> If that's accurate, I think a constant `vscale` is not sufficient.

The main problem here is one of representation. In the ARM implementation, SVE vectors alias with SIMD vectors, so you need to be careful on how you write to them.

If you don't have a way to separate SVE from SIMD, you'll have trouble generating either code. If you separate them completely, you'll have trouble worrying about the aliasing.

Having a flag (even as boolean "i1 vscale") is enough. It needs to be a constant because of how scalar evolution will work on the predicate vectors, but I'll let Graham explain that in more depth, as I'm only "familiar" at this point.

cheers,
--renato


https://reviews.llvm.org/D32737





More information about the llvm-commits mailing list