Partially stabilize LoongArch target features

[heiher]

Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.

Specifically, this PR stabilizes the following target features:

• f
• d
• frecipe
• lasx
• lbt
• lsx
• lvz

Docs PR: rust-lang/reference#1707

r? @Amanieu

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[RalfJung]

If "d" and "f" work anything like the RISC-V features of the same name, they should not be stabilized yet. We need to figure out #116344 and #131799 for LoongArch first.

Does any of the other features ever have any effect on calling conventions or ABI?

[heiher]

If "d" and "f" work anything like the RISC-V features of the same name, they should not be stabilized yet. We need to figure out #116344 and #131799 for LoongArch first.

Does any of the other features ever have any effect on calling conventions or ABI?

Thank you! Other than f and d, there are no other target features affecting the calling convention and ABI.

[ehuss]

This will need a PR for documentation at https://github.com/rust-lang/reference/blob/master/src/attributes/codegen.md, and a lang (+whoever?) FCP.

[Amanieu]

• relax refers to linker relaxation support and may not be appropriate to expose as a target feature.
• ual refers to support for unaligned memory access, similar to strict-align on ARM targets. It's probably fine to stabilize as-is, but we may want to double-check with other targets if we want to have a consistent feature name between all of them (alternatively it's also fine to make the feature target-specific).

[RalfJung]

Also to be clear, ual can only affect how unaligned accesses are codegen'd, and nothing else. See this recent discussion on Zulip.

If we have target feature docs somewhere, they should clarify hat unaligned accesses are still UB except when performed via {read,write}_unaligned.

[heiher]

I agree with skipping these two target features and stabilizing them at a more appropriate time.

[Amanieu]

r? lang

[heiher]

This will need a PR for documentation at https://github.com/rust-lang/reference/blob/master/src/attributes/codegen.md, and a lang (+whoever?) FCP.

PR: rust-lang/reference#1707

[bors]

☔ The latest upstream changes (presumably #134794) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #138523) made this pull request unmergeable. Please resolve the merge conflicts.

[heiher]

If "d" and "f" work anything like the RISC-V features of the same name, they should not be stabilized yet. We need to figure out #116344 and #131799 for LoongArch first.

That's resolved. Can we start the FCP now?

[heiher]

r? lang (A gentle ping. :)

[heiher]

I think this is ready for final comment period. Could someone from the lang team take a look?

cc @rust-lang/lang

[RalfJung]

If "d" and "f" work anything like the RISC-V features of the same name, they should not be stabilized yet. We need to figure out #116344 and #131799 for LoongArch first.

That's resolved. Can we start the FCP now?

Has it? They are still listed in the PR description.

[traviscross]

Amanieu joined us on the call today to talk us through this. This seems fine, modulo what @RalfJung had mentioned about "d" and "f", so I'm going to propose FCP merge and file an immediate concern to that effect.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• what-about-d-and-f (Partially stabilize LoongArch target features #135015 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

@rfcbot reviewed

[traviscross]

@rfcbot concern what-about-d-and-f

In #135015 (comment), @RalfJung raised a concern:

If "d" and "f" work anything like the RISC-V features of the same name, they should not be stabilized yet. We need to figure out #116344 and #131799 for LoongArch first.

Does any of the other features ever have any effect on calling conventions or ABI?

Let's figure out the answer to that.

[RalfJung]

Ah I think the point is, there are now ABI checks set up for this, so the target features should be safe.

I hope they are, I don't have any experience with this target. The target is extremely similar to RISC-V though, and RISC-V has a lot more eyes on it and more people have experience in it, so it may make sense to stabilize "f" and "d" there first if we are confident about this. @Amanieu do you know if there are any blockers for that?

[RalfJung]

Also, @heiher given that 4 of the features on the original list have subtle ABI questions, could you double checks that all the other features are harmless in that regard?

[heiher]

Also, @heiher given that 4 of the features on the original list have subtle ABI questions, could you double checks that all the other features are harmless in that regard?

f and d already have ABI compatibility checks in place. For lsx, 128-bit vectors are always passed through general-purpose registers, while for lasx, 256-bit vectors are always passed on the stack — so all four features are ABI-safe. The other features don’t affect the ABI and are harmless in that regard. Thanks.

[nikomatsakis]

@rfcbot reviewed