Compiler does not recognize the reserve-x18 target feature

[Darksonn]

On the aarch64-unknown-none target, specifying the reserve-x18 target feature using the flag -Ctarget-feature=+reserve-x18 results in the following warning:

warning: unknown feature specified for `-Ctarget-feature`: `reserve-x18`
  |
  = note: it is still passed through to the codegen backend
  = help: consider filing a feature request

The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM.

This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (more info). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass -ffixed-x18 but not -fsanitize=shadow-call-stack (which is only used for non-dynamic SCS).

Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18.

Related to #96472.
Related to this thread on LKML.

[bjorn3]

This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.

[ojeda]

This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.

Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like -Ctarget-feature, but that it ensures it is set the same way for all compilation units).

[JamieCunliffe]

This affects the ABI, right?

There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards.

LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers. The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as void test() can't be called in a quick test.

Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.