Add v9 and leoncasa target feature to sparc

[taiki-e]

This adds the following two unstable target features:

• v9: SPARC-V9 instructions (LLVM definition)
  • IIUC, this is needed to implement Generate correct symbols.o for sparc-unknown-none-elf #131222 more robustly.
    • See also Generate correct symbols.o for sparc-unknown-none-elf #131222 (comment)
  • This is also needed to implement inline assembly support for SPARC (Basic inline assembly support for SPARC and SPARC64 #132472 (comment))
  • This is also needed to implement Support SPARC and SPARC64 (experimental) taiki-e/atomic-maybe-uninit#31 (depend on inline assembly support) more robustly.
• leoncasa: CASA instruction¹ of LEON3 and LEON4 processors (LLVM definition, LLVM feature name: hasleoncasa)
  • This is needed to implement Support SPARC and SPARC64 (experimental) taiki-e/atomic-maybe-uninit#31 (depend on inline assembly support) more robustly.

In LLVM 19, LLVM emits EM_SPARC32PLUS if the v9 feature is enabled (llvm/llvm-project@fb7f65b)
My understanding is that (some) use of the v9 feature may eventually be replaced by the v8plus feature in LLVM 20 (llvm/llvm-project@aca971d), but there is no other good way in the current LLVM 19.

cc @thejpster @glaubitz

r? workingjubilee

@rustbot label +O-SPARC +A-target-feature

Footnotes

1. Atomic CAS instruction ↩

[glaubitz]

CC @psumbera @rorth @koachan @jrtc27 @andreas-gaisler

[koachan]

I'm not very familiar with Rust, but from what I can tell it looks okay.

Also, a word on this:

My understanding is that (some) use of the v9 feature may eventually be replaced by the v8plus feature in LLVM 20 (llvm/llvm-project@aca971d), but there is no other good way in the current LLVM 19.

v8plus is a purely ABI flag, intended to signal that the G and O registers are 64-bit. It is separated in LLVM because we want to be GCC-compatible and so need to cater to a particular usecase in which V9 instructions are desired, but all registers are to be kept 32-bit (effectively banning instructions like CASXA which needs 64-bit registers to operate).
If Rust doesn't want to do this, it could always set (or delete) v9 and v8plus together...

[taiki-e]

v8plus is a purely ABI flag, intended to signal that the G and O registers are 64-bit. It is separated in LLVM because we want to be GCC-compatible and so need to cater to a particular usecase in which V9 instructions are desired, but all registers are to be kept 32-bit (effectively banning instructions like CASXA which needs 64-bit registers to operate). If Rust doesn't want to do this, it could always set (or delete) v9 and v8plus together...

Thanks for the clarification. I think separating v8plus from v9 is the correct behavior (eventually) for Rust as well, as we do not want the ABI to be changed by -C target-cpu (-mtune).

However, we are using LLVM 19 which ties v9 and v8plus together and need a way to fix a bug in rustc that incorrectly always uses EM_SPARC32PLUS (#130172).

In #131222 we are trying to adopt the same approach as in LLVM 19, but actually adding the v8plus feature and mapping them to the v9 feature in LLVM 19 may be a better way here. (The implementation of it is in 0849356 and even if we merge the LLVM 19's approach, we will probably need it when updating to LLVM 20.)

[bors]

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