[llvm] [LV] Add initial support for vectorizing literal struct return values (PR #109833)

[David Sherwood via llvm-commits]

================
@@ -9607,7 +9624,7 @@ void VPReplicateRecipe::execute(VPTransformState &State) {
             VectorType::get(UI->getType(), State.VF));
         State.set(this, Poison);
       }
-      State.packScalarIntoVectorValue(this, *State.Lane);
+      State.packScalarIntoWideValue(this, *State.Lane);
----------------
david-arm wrote:

Given you're setting the state to potentially be a struct of vectors, what happens if we use the result in something that isn't extractvalue? For example, can you see what happens with IR like this?

```
  %call = tail call { float, float } @baz(float %in_val)
  store { float, float } %call, ptr %gep, align 8
```

? I'd hope that LoopVectorizationLegality prevents it, since you're only permitting return types to be structs. However, I do worry that essentially this patch is opening up vectorisation for more use cases than just extracting a value that we haven't tested yet. For the case of the store you would have to effectively treat this as an interleaving store to ensure the data is correctly laid out in memory.

In general though, these VPlan changes are essentially going down the path of defining what it means to vectorise any arbitrary operation that has a struct as either input or output. It sets in stone a single mechanism for vectorising such types, which is that a struct of scalars is treated as a struct of vectors once vectorised. However, I can also imagine cases where we might want to treat it as a vector of structs - see the store example above. @fhahn is this what you were worried about with this patch?

https://github.com/llvm/llvm-project/pull/109833