Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Our 32-bit Sparc handling isn't quite correct yet #132585

Closed
workingjubilee opened this issue Nov 4, 2024 · 1 comment · Fixed by #132552
Closed

Our 32-bit Sparc handling isn't quite correct yet #132585

workingjubilee opened this issue Nov 4, 2024 · 1 comment · Fixed by #132552
Labels
C-bug Category: This is a bug. O-linux Operating system: Linux O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Nov 4, 2024 •
edited
Loading

See:

We need to, for compiling for 32-bit SPARC, distinguish when we should use the appropriate Elf Machine for V8 vs. V8+. This is necessary because this is the primary way of detecting instruction incompatibility for the architecture: providing a CPUID via instruction or register read at runtime hadn't become fashionable yet.
@workingjubilee workingjubilee added C-bug Category: This is a bug. O-linux Operating system: Linux O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 4, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 4, 2024
@workingjubilee workingjubilee mentioned this issue Nov 4, 2024
Merged
@taiki-e
Copy link
Member

taiki-e commented Nov 4, 2024

An additional complication here is that LLVM also works differently in different versions for this.

  • LLVM 18 always uses EM_SPARC (code)
  • LLVM 19 uses EM_SPARC32PLUS if the v9 feature (which is also a feature that indicates whether certain instructions are available) is enabled, otherwise EM_SPARC (code)
  • LLVM 20 (unreleased) uses EM_ SPARC32PLUS if the v8plus feature (which is an independent feature not tied to any other feature) is enabled, otherwise EM_SPARC (code)

#131222 implements the behavior of LLVM 19 somewhat imperfectly, and the feature will be added in #132552 can be used to make it exactly match LLVM 19.

The behavior of LLVM 20 is consistent with that of GCC (that -mcpu=v9 does not imply -mv8plus), and I think eventually we will need to match it. (See #132552 (comment) for the motivation for this behavior.)

IIUC, my patch mentioned in #132552 (comment) (0849356) works the same way as LLVM in each LLVM version. (Of course, the problem with that patch is that it behaves differently depending on the LLVM version (until LLVM 20 is the minimal LLVM version).)

@jieyouxu jieyouxu removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Nov 4, 2024
This was referenced Nov 7, 2024
Merged
Open
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Nov 9, 2024
@matthiaskrgr
Rollup merge of rust-lang#132552 - taiki-e:sparc-target-feature, r=wo…
b9d4ef1 
…rkingjubilee

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

This adds the following three unstable target features:

- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
  - Relevant to rust-lang#131222 (comment)
  - Relevant to rust-lang#132472 (comment)
  - This is also needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
  - 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 rust-lang#132585 (comment) for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
  - This is needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.

[^1]: Atomic CAS instruction

[sparc-v9]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-v8plus]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Nov 9, 2024
@rust-timer
Unrolled build for rust-lang#132552
6a14d06 
Rollup merge of rust-lang#132552 - taiki-e:sparc-target-feature, r=workingjubilee

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

This adds the following three unstable target features:

- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
  - Relevant to rust-lang#131222 (comment)
  - Relevant to rust-lang#132472 (comment)
  - This is also needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
  - 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 rust-lang#132585 (comment) for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
  - This is needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.

[^1]: Atomic CAS instruction

[sparc-v9]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-v8plus]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
mati865 pushed a commit to mati865/rust that referenced this issue Nov 12, 2024
@matthiaskrgr @mati865
Rollup merge of rust-lang#132552 - taiki-e:sparc-target-feature, r=wo…
60a8436 
…rkingjubilee

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

This adds the following three unstable target features:

- `v9`: SPARC-V9 instructions ([LLVM definition][sparc-v9])
  - Relevant to rust-lang#131222 (comment)
  - Relevant to rust-lang#132472 (comment)
  - This is also needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.
- `v8plus`: SPARC-V8+ ABI ([LLVM definition][sparc-v8plus])
  - 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 rust-lang#132585 (comment) for more.
- `leoncasa`: CASA instruction[^1] of LEON3 and LEON4 processors ([LLVM definition][sparc-leoncasa], LLVM feature name: `hasleoncasa`)
  - This is needed to implement taiki-e/atomic-maybe-uninit#31 (depends on inline assembly support) more robustly.

[^1]: Atomic CAS instruction

[sparc-v9]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-v8plus]: https://github.com/llvm/llvm-project/blob/f5e4ffaa49254706ad6fa209de8aec28e20f0041/llvm/lib/Target/Sparc/Sparc.td#L37-L39
[sparc-leoncasa]: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/LeonFeatures.td#L32-L37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: This is a bug. O-linux Operating system: Linux O-SPARC Target: SPARC processors T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
4 participants
@jieyouxu @taiki-e @workingjubilee @rustbot