rustc_target: aarch64: Remove deprecated FEAT_TME

[maurer]

ARM has withdrawn FEAT_TME

https://developer.arm.com/documentation/102105/lb-05/

LLVM has dropped support for generating it
llvm/llvm-project#167687

@rustbot label llvm-main

r? @durin42

[rustbot]

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

cc @Amanieu, @folkertdev, @sayantn

[maurer]

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

cc @Amanieu, @folkertdev, @sayantn

Having this patch up with the llvm-main tag should allow the LLVM integration test to continue running. I will produce a separate patch removing usage of FEAT_TME from stdarch and merge that first.

[maurer]

See rust-lang/stdarch#1960

[sayantn]

I don't think we can just remove it, this is in stable

[folkertdev]

The feature is apparently stable, but none of the intrinsics are, so we can remove those at least I think

[folkertdev]

But yeah removing a stable target feature will require T-lang involvement, even though I assume it'll be fine to remove the feature.

[maurer]

This causes build failures when using the latest LLVM when building tests (and so if we leave it in, anyone using the feature will hit a build failure on LLVM as soon as we update LLVM). If we want to keep tme as an available feature, we may need to add a filter on cpu features being passed to LLVM to not send ones that have been removed from LLVM. Would that be reasonable?

[sayantn]

we can just add a "tme" => [] in rustc_codegen_llvm::llvm_util, this will just pass nothing to LLVM for tme, which will avoid the error. then we can phase this out maybe. But anyway, for now let's remove the intrinsics

[folkertdev]

you can even make that conditional on the LLVM version, to not break anything overnight. I think that is the best step forward right now, and then T-lang can decide what to do long term. We can probably do a crater run and then remove it, but maybe they want to see a warning for a while.

[maurer]

you can even make that conditional on the LLVM version, to not break anything overnight.

While I understand keeping the feature around in case someone explicitly turned it on even though it does nothing, my understanding is that this feature was withdrawn because there are very few (no?) CPU implementations actually supporting it, just simulators and specs, so just ceasing to pass the feature shouldn't break anything.

If you'd still prefer to, I'll re-alter the patch again, but I suppose there's no rush because we need to land the stdarch change first and merge it back.

[folkertdev]

If you'd still prefer to, I'll re-alter the patch again, but I suppose there's no rush because we need to land the stdarch change first and merge it back.

I understand, it's just that we have procedures to never merge any breaking changes to the language without the green light from T-lang. Things have slipped through in the past, and it's just easier to have that strict rule.

I suspect T-lang will just rule to remove the feature, given that it likely has zero usage: all intrinsics to use it were unstable, I don't think this feature changes codegen, so the only theoretical risk is if someone wrote some code using inline assembly that relies on the target feature being enabled?