Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file

[taiki-e]

This adds the following three 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 role has been replaced by v8plus
  • This is also needed to implement inline assembly support for SPARC (Basic inline assembly support for SPARC and SPARC64 #132472 (comment)) EDIT: no longer needed 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.
• v8plus: SPARC-V8+ ABI (LLVM definition)
  • This is added in LLVM 20. In LLVM 19 and older, it is emulated to work the same way as LLVM in each LLVM version.
  • See Our 32-bit Sparc handling isn't quite correct yet #132585 (comment) for more.
• 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.

cc @thejpster @glaubitz

r? workingjubilee

Closes #132585

@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.

[rustbot]

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

[taiki-e]

Added commit to add v8plus target feature and use it (the same one that mentioned in #132552 (comment)). This fixes #132585 and should work the same way as LLVM in each LLVM version. (See #132585 (comment) for more info.)

(If it would be better to separate that commit into a separate PR, I would be happy to separate it.)