[llvm] [LV] Add initial support for vectorizing literal struct return values (PR #109833)
Florian Hahn via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 14 12:49:09 PDT 2024
fhahn wrote:
> > VPlan supports recipes that produce multiple results, e.g. as `VPInterleaveRecipe`. The recipe then would take care of de-interleaving the result, this would help avoid the need to modify various places in VPTransformState.
>
> I'm a little unclear on how this would work. Do you mean making `VPWidenCallRecipe`/`VPReplicateRecipe` return a value for each element of the struct? I'm not sure what to do around the `extractvalues` in the original IR/plan, I guess you'd have to replace them with the widen call recipe while constructing the plan?
>
Hm, yes, `VPWidenCallRecipe` could define one VPValue per element vector and take care of splitting up the return value directly, which may also allow more accurately estimating the cost overhead. It might be worth introducing a separate recipe for calls that return multiple results. Perhaps @ayalz has any additional thoughts?
One question is how to deal with VPReplicateRecipe, I suppose we would need a version as well that produces multiple results.
> I'm not sure what to do around the `extractvalues` in the original IR/plan, I guess you'd have to replace them with the widen call recipe while constructing the plan?
When lowering `extractvalue`'s, they would be replaced by just looking up the VPValue from the first multi-def operand at the index of the extract.
> > I might have missed it, but could you make sure that there are tests with struct return values that cannot be widened?
>
> There's a few tests in `llvm/test/Transforms/LoopVectorize/struct-return.ll` (`negative_mixed_element_type_struct_return`, `test_named_struct_return`, `test_overflow_intrinsic`).
Thanks!
https://github.com/llvm/llvm-project/pull/109833
More information about the llvm-commits
mailing list