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

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen added a comment.

Hi @efriedma, I had to give this a moment to sink in, but you are right about the widening not having to assume anything about the target's vector format, I had my wires crossed here.

The widening operation done here is purely performed on a conceptual vector. Widening <vscale x 1 x i64> to <vscale x 2 x i64> by appending undef elements at the end of the vector, is actually the operation that's performed by INSERT_SUBVECTOR (and vice-versa for EXTRACT_SUBVECTOR), which we then implement efficiently with UZP1 and UUNPKLO if the (min) element count is a power of two.

What confused me was that there were no such shuffles in the code which made me think we had to care about the unpacked format. But that makes sense, because `<vscale x 1 x i64> %arg` coming into the function has already been widened by the caller. There is no need to extract a subvector, and then insert the subvector again into an UNDEF to get a widened vector, because the widened value/operand is already available.

Based on that, I no longer see the need for the kind of widening as proposed here, so this patch can probably be closed/abandoned.

> 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?

This would indeed only apply to types where the element-count is a power of two (otherwise it would imply FMT3). I'm not sure what the best approach would be for non-power-of-two element counts or how to implement this. At least the loop vectorizer should never pick such a VF, so I'd hope we don't need to worry about this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105119