(release 20.x non-upstream patch) [LV] Add initial support for vectorizing literal struct return values

[MacDue]

This patch adds initial support for vectorizing literal struct return values. Currently, this is limited to the case where the struct is homogeneous (all elements have the same type) and not packed. The users of the call also must all be extractvalue instructions.

The intended use case for this is vectorizing intrinsics such as:

declare { float, float } @llvm.sincos.f32(float %x)

Mapping them to structure-returning library calls such as:

declare { <4 x float>, <4 x i32> } @Sleef_sincosf4_u10advsimd(<4 x float>)

Or their widened form (such as @llvm.sincos.v4f32 in this case).

Implementing this required two main changes:

1. Supporting widening extractvalue
2. Adding support for vectorized struct types in LV

• This is mostly limited to parts of the cost model and scalarization

Since the supported use case is narrow, the required changes are relatively small.

---

Downstream issue: #87

[MacDue]

This PR is a copy of the LLVM PR llvm/llvm-project#109833, which was not possible to upstream for the release.

PR now merged upstream.

[dcandler]

Since this is a downstream change, it should follow the downstream patch policy: https://github.com/arm/arm-toolchain/blob/arm-software/CONTRIBUTING.md#downstream-patch-policy

If it's a critical change that didn't make the upstream release, then please make sure it's tracked appropriately.

[MacDue]

Hey @dcandler, I've gone over the requirements and attempted to address them for this PR. The main one that's unclear to me is "source change should be annotated with a comment", which seems slightly impractical for non-trivial changes
(e.g. this change spans multiple files and functions).

• The pull request description or comment must contain a justification of why the patch isn't being made upstream. This should include links to any previous attempts to upstream.

PRs include links to LLVM patches, the main release for the patch(es) not being upstream is long review times.

• The commit message for a new downstream patch must include Downstream issue:# where # is an issue that contains the reason for the downstream patch.

I've created tracking issue #87.

• The source change should be annotated with a comment including the #, if there are multiple lines changed a single comment for the block can be used.

I'm not sure how to go about this one. It seems impractical for non-trivial changes.

• The commit message that removes an existing downstream patch, such as when the upstream equivalent lands, must include Removes downstream issue:#.

N/A (yet)

• New files in the arm-toolchain repository must include the LLVM license, with the standard header comment and SPDX identifier.

N/A

• New files added to an external project like picolibc or newlib must follow the licensing and copyright of the external project.

N/A

• Any patch that causes the Arm Toolchain to deviate from upstream behavior, such as a new command-line option, must have user documentation. See Downstream Feature Documentation for the location and required contents.

Only #84 should noticeably change behaviour (as sincos calls become vectorizable with -fveclib=ArmPL/SLEEF)

[MacDue]

cc @david-arm

[dcandler]

Thanks - this is the first time attempting to apply the policy, so it's also a bit of a test of the policy itself.

• The commit message for a new downstream patch must include Downstream issue:# where # is an issue that contains the reason for the downstream patch.

I think the text in the commit message might need to be exactly Downstream issue:#87 since the intention is to have scripting be able to read the issue number (e.g. in a pre-merge check) and I'm not sure how strict the scripts will be with keeping the formatting consistent.

• The source change should be annotated with a comment including the #, if there are multiple lines changed a single comment for the block can be used.

I can see it as being a bit of a burden here, but it's also meant to help with the automated scanning of the sources to ensure everything is tracked. Again though, the scripts and infrastructure for those checks is not in place yet - so if we did relax that requirement it might still need adding back in later.
However the other motivation for this was to make it easier to see where/why something was changed when resolving a merge conflict, which any downstream change has the potential to create. But on a release branch, I'd expect a conflict less often.

[MacDue]

I think the text in the commit message might need to be exactly Downstream issue:#87 since the intention is to have scripting be able to read the issue number (e.g. in a pre-merge check) and I'm not sure how strict the scripts will be with keeping the formatting consistent.

Just checking: Are PRs to this repo squash merged (like upstream LLVM) -- so only the PR description needs updating to update the commit message?

I can see it as being a bit of a burden here, but it's also meant to help with the automated scanning of the sources to ensure everything is tracked.

What do you suggest we do for these PRs?

[dcandler]

Yes, squashing is enabled (and currently the default) so you can use the updated description when merging.

For the annotations, I think we should stick to the policy as written since that's what was agreed; if it's not followed then it defeats the purpose of having the policy in the first place.

[MacDue]

I've added the annotations for this PR. Since there are no examples in the guide, I just made up a format for them.

[dcandler]

Formatting of the annotations looks fine to me - we can probably expand the policy with more examples/guidelines once we've gotten to see how it works out in practice (and any automated checking is implemented, if anything stricter is needed).

[MacDue]

The corresponding upstream PR has now been merged (llvm/llvm-project#109833), so I've removed the comments as this is now a simple cherry-pick.

The other PRs are still downstream.

[dcandler]

A cherry pick to our downstream release branch is still considered a downstream change to which the policy would apply, since it causes our branch to diverge from the upstream version. To avoid making it a downstream change, it would need to be cherry-picked to the upstream release branch, where it could be automerged to ours.

[MacDue]

Alright, I've added the comments back 👍