[PATCH] D105119: [SVE] Fix incorrect codegen when inserting vector elements into widened scalable vectors

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> FMT1: <e0, _, e1 _ | e2, _, e3, _ | ... > (elements unpacked in #vscale containers)

Could you clarify how you expect FMT1 to work for `<vscale x 3 x i32>`? Or is it only meant to apply to types where the element count is a power of two?

I agree FMT3 is pretty unlikely to be useful in practice.

> Given the above reasoning that LLVM implements FMT1, this would discard option 3 and would make option 5 unnecessary since widening has only a single meaning.

Each target has control over how it prefers to convert a vector with an illegal type to a legal type, by overriding getPreferredVectorAction().  There isn't any global "LLVM" layout; there's just what each particular target requests for each type.  LLVM's target-independent code then has to take that request, and figure out how to turn it into actual code.

So we could easily end up with a situation where, for some combination of targets/vectors, we want FMT1, and for some other combination of targets/vectors, we want FMT2.  In that case, we probably want TypeWidenVector to mean FMT2.  That's where options 3 and 5 comes into play.  For option 5, we can share most of the legalization code; most operations would be legalized the same way with either layout.

Another benefit of option 5 is that it separates the choice of layout from the distinction between fixed/scalable vectors.  They aren't really fundamentally tied together; a target could choose to use FMT1 for a fixed-width vector.  (At the moment, I can't think of any target that would want to do that, but I'm not that familiar with all the various vector instruction sets out there.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105119