Fix handling of x18 in AArch64 inline assembly on ohos/trusty or with -Zfixed-x18

[taiki-e]

Currently AArch64 inline assembly allows using x18 on ohos/trusty or with -Zfixed-x18.

rust/compiler/rustc_target/src/asm/aarch64.rs

Lines 74 to 76 in 7db7489

	pub(crate) fn target_reserves_x18(target: &Target) -> bool {
	target.os == "android" || target.os == "fuchsia" || target.is_like_osx || target.is_like_windows
	}

However, x18 is reserved in these environments and should not be allowed in the input/output operands of inline assemblies as it is in Android, Windows, etc..

rust/compiler/rustc_target/src/spec/targets/aarch64_unknown_linux_ohos.rs

Line 19 in 7db7489

features: "+reserve-x18".into(),

rust/compiler/rustc_target/src/spec/targets/aarch64_unknown_trusty.rs

Line 18 in 7db7489

features: "+neon,+fp-armv8,+reserve-x18".into(),

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Lines 764 to 771 in 7db7489

	// -Zfixed-x18
	if sess.opts.unstable_opts.fixed_x18 {
	if sess.target.arch != "aarch64" {
	sess.dcx().emit_fatal(FixedX18InvalidArch { arch: &sess.target.arch });
	} else {
	features.push("+reserve-x18".into());
	}
	}

(As for ohos, +reserve-x18 is redundant since 7a966b9 that starting using llvm's ohos targets. So removed it from target-spec.)

This fix may potentially break the code for tier 2 target (aarch64-unknown-linux-ohos). (As for others, aarch64-unknown-trusty is tier 3 and -Zfixed-x18 is unstable so breaking them should be fine.)
However, in any case, it seems suspicious that the code that is broken by this was sound.

r? @Amanieu

@rustbot label O-AArch64 +A-inline-assembly

[rustbot]

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

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[taiki-e]

cc @Darksonn (who added -Zfixed-x18 in #124655)
cc @randomPoison (who added aarch64-unknown-trusty in #129490)

[Darksonn]

Is it possible to avoid duplicating this logic? It seems prone to getting out of sync with llvm.

[Amanieu]

I can't think of a good way to avoid the duplication unfortunately.

[randomPoison]

This seems correct as far as Trusty is concerned, thanks @taiki-e for addressing this ❤️ I wasn't aware of this when I added the Trusty targets, but as far as I know we don't directly use the x18 register in inline assembly from Rust, so this shouldn't introduce any problems for Trusty 👍

[Amanieu]

@bors r+

[bors]

📌 Commit 687dc19 has been approved by Amanieu

It is now in the queue for this repository.