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

[Renato Golin via Phabricator via llvm-commits]

rengolin added inline comments.


================
Comment at: docs/LangRef.rst:2749
+of size zero are not allowed. For scalable vectors, the number of
+elements is an unknown integer multiple of the number of elements.
 
----------------
hfinkel wrote:
> This doesn't seem strong enough. We need the unknown multiple to be the *same* for any given type (at least within a given function).  We also need a relationship between vectors of different underlying types (so that zext/sext/etc. make sense). Otherwise, you can't even sensibly add them together (for example). I realize that it says something about an unknown vector length above, but we need to translate that statement into semantics that make sense for the vectors themselves.
It's not that simple. Both SVE and RISC-V can have vector multiplier changes in the middle of a function (via system register or similar). Neither of them *want* that to be the norm, but IIRC, RISC-V doesn't want it to change inside a function and SVE wants it to be the same for the whole program.

I totally agree with you that leaving it open is a huge can of worms, and wanting a per-function change would probably need new annotation on functions, which if ever done, should be orthogonal to this change (or would lead us into madness).

I second your proposal that we fix the semantics in LLVM, for now, that the "unknown width" is the same throughout the program and that the existing relationship between fixed vectors extends to scalable vectors.

If you look at the changes in this patch series, it assumes that behaviour already, by getting new vector types of half-size with double-elements and so on.

IFF RISC-V wants to extend the logic to be per-function, then we will need to do a much more extensive analysis on the passes, especially around inlining and function calls. I strongly propose we don't look at it right now and fix the semantics as proposed above.

In my analysis, with that semantics, I don't see a big impact on any existing non-scalable optimisations. With vectorisation passes being run at the end of the pipeline, even for scalable code, most of the existing pipeline will still be relevant, too.


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

https://reviews.llvm.org/D32530