fuchsia: dynamically enable fix-cortex-a53-835769 for generic CPUs

[PiJoules]

Previously, +fix-cortex-a53-835769 was statically included in base.features for aarch64-unknown-fuchsia. This caused the Cortex-A53 erratum workaround to be unconditionally enabled regardless of the selected target CPU (e.g., when passing -C target-cpu=cortex-a73).

The behavior we want is to have it enabled by default only for the generic CPU (armv8-a), and it should be togglable via the normal -Ctarget-features= flag. This matches the target-feature logic in clang.

AI: Note gemini was used to help verify this does match Clang's behavior and write out the matrix of different test invocations. I reviewed this code to the best of my ability before submitting.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: codegen, compiler
• codegen, compiler expanded to 76 candidates
• Random selection from 20 candidates

[PiJoules]

cc @erickt @ilovepi

[petrochenkov]

r? @RalfJung afaik you've been reworking the target feature system, not sure how this fits into that

[rustbot]

RalfJung is not on the review rotation at the moment.
They may take a while to respond.

[RalfJung]

This hack (wtf is even going on there) looks LLVM-specific but the file you put it in is also used for other backends.

View changes since the review

[RalfJung]

and it should be togglable via the normal -Ctarget-features= flag.

For that you have to make it a Rust target feature, i.e., add it in compiler/rustc_target/src/target_features.rs. This PR doesn't do that. It would be by far the silliest target feature we have I think.^^

I can give general advice for target feature but cannot review whatever insanity this weird hack is. I just wonder if this is really the best way to deal with whatever problem this solves.

@rustbot reroll

[RalfJung]

Previously, +fix-cortex-a53-835769 was statically included in base.features for aarch64-unknown-fuchsia. This caused the Cortex-A53 erratum workaround to be unconditionally enabled regardless of the selected target CPU (e.g., when passing -C target-cpu=cortex-a73).

Yes, features is for things that must be configured like that on this target.
There was recently another PR where people also lamented that it's unfortunate that target spec features cannot be overwritten with -Ctarget-feature. However, it is not a solution to instead add target-specific hacks in target-independent code. So I don't think we should land this. If we need a concept of base target features that can be overwritten by -Ctarget-feature, then (a) we should figure out why features in the target spec doesn't behave like that, and (b) if features can't be changed, add a new target spec field so we can properly represent this in a generic way.

[RalfJung]

Actually, I mixed things up. features in the target spec can be overwritten by -Ctarget-feature. But they cannot be overwritten by -Ctarget-cpu. It is unclear what that would even mean.

[RalfJung]

TBH IMO this would be best handled by LLVM. LLVM can realize that the selected target CPU does not need whatever that "fix" thing is any more, and then stop applying it. Asking frontends to do this means that it requires hacks in a whole bunch of places as it does not follow the usual structure of a target feature.

Cc @nikic

[JonathanBrouwer]

Also not at all familiar with this code
@rustbot reroll

[adwinwhite]

@rustbot reroll

[chenyukang]

@rustbot reroll

[rust-bors]

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