[PATCH] D32530: [SVE][IR] Scalable Vector IR Type

[David Greene via Phabricator via llvm-commits]

greened added a comment.

> We need to clarify on insertelement/extractelement. Maybe already done in some other patches, but that clarification should be part of this patch.
>  Is the "length of val" under the semantics "scalable * n" in <scalable n x ElemTy>, right? Or is it still n?

I am not sure how it could be anything but `n`.  If you don't know how long the vector is, you can't correctly generate an index beyond `n`.  I assume for vectors of length > n one would have to use `shufflevector` or something similar (using `vscale` and `stepvector` as Graham mentioned) to get the elements you want to the lower `n` positions.

Either way, the semantics and any restrictions certainly need to be documented.

> Going with length of val being "scalable * n", if there is an optimization that takes advantages of poison value being returned by evaluating "idx >= n" at compile time, we need to disable that for scalable vector. Also, if any verifier is checking whether constant idx value is less than n, we need to disable that for scalable vector.

If the index is still restricted by `n` then this shouldn't be an issue.



================
Comment at: docs/LangRef.rst:2755
+time. The size of a specific scalable vector type is thus constant within
+IR, even if the exact size in bytes cannot be determined until run time.
 
----------------
Just want to double-check: there is nothing about scalable vectors that assumes all vector types have the same bit width, correct?  Can <scalable 1 x float> have a different bit width from <scalable 1 x double>?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D32530/new/

https://reviews.llvm.org/D32530