Add amdgpu target

[Flakebi]

Add amdgpu target to rustc and enable the LLVM target.

Fix compiling core with the amdgpu:
The amdgpu backend makes heavy use of different address spaces. This
leads to situations, where a pointer in one addrspace needs to be casted
to a pointer in a different addrspace. bitcast is invalid for this
case, addrspacecast needs to be used.

Fix compilation failures that created bitcasts for such cases by
creating pointer casts (which creates an addrspacecast under the hood)
instead.

MCP: rust-lang/compiler-team#823
Tracking issue: #135024
Kinda related to the original amdgpu tracking issue #51575 (though that one has been closed for a while).

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @GuillaumeGomez (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

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

This PR changes how LLVM is built. Consider updating src/bootstrap/download-ci-llvm-stamp.

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

This PR modifies config.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[jieyouxu]

r? jieyouxu

[workingjubilee]

cc @eddyb Hello, tagging you for domain expertise if you want to chime in.

[jieyouxu]

Thanks for the PR, @Flakebi. I'm going to request that you open a MCP at https://github.com/rust-lang/compiler-team/issues/ to gauge team consensus for adding this target, primarily to give compiler team members some opportunity to ask clarifying questions and register possible concerns, since:

• Adding this target requires modifying codegen_llvm in a non-trivial way (emitting at times
  addrspacecast instead of bitcast). In particular, as you stated, this target has a
  non-conventional addrspace usage model that I believe we don't quite observe in other existing
  targets:

  The amdgpu backend makes heavy use of different address spaces. This leads to situations,
  where a pointer in one addrspace needs to be casted to a pointer in a different addrspace.
  bitcast is invalid for this case, addrspacecast needs to be used.

• This requires modifying the LLVM build to also include the AMDGPU backend.

• This target seems to be intended for many different CPUs of varying hardware generation, but the
  present target definition defaults to gfx900.

Note that usually adding more "conventional" Tier 3 targets do not need to go through the MCP process, but this target looks not so conventional.

[jieyouxu]

@rustbot author

[Flakebi]

Thank you for the quick review!

I opened an MCP here: rust-lang/compiler-team#823

[traviscross]

cc @ZuseZ4

[bors]

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

[Flakebi]

I removed changes apart from adding the target and enabling the LLVM backend from this PR. They will go into their own PRs.
I extended the platform-support documentation a bit.

There is now a tracking issue: #135024

[bors]

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

[Flakebi]

Rebased to fix conflicts and fix tests, no changes to the target.

[Flakebi]

Extend target documentation.
I found out that HIP can be used to load/run amdgpu binaries as well (in addition to HSA), and it works on Linux and Windows!
Diff

[workingjubilee]

oh, that's awesome! that should make testing this much easier.

[workingjubilee]

#135030 first, and then this should land when that flag has been included for the target.

[workingjubilee]

Right, it's in. Please rebase and include a test that specifically verifies the target doesn't work unless -Ctarget-cpu has been set. I know that we already did it for a target-spec.json target but we should make sure this doesn't get unset by a later PR.

[Flakebi]

Thanks! I rebased and added a second commit for requiring -Ctarget-cpu (to make it easier to review the new changes, if you prefer, I can squash them). Thanks for the reminder about adding tests, I probably would have forgotten otherwise. Definitely makes sense to have them.

[workingjubilee]

Thanks!

...uh, I have a question now, hm.

-Ctarget-cpu is going to show up in the metadata for our rlibs, right? So that we won't link ones with mismatching CPUs together? I felt confident about this a second ago but then I inspected the thought and I'm not entirely sure how the invalidation logic actually goes, since it would make sense for it to be attemptable usually.

[Flakebi]

-Ctarget-cpu is going to show up in the metadata for our rlibs, right? So that we won't link ones with mismatching CPUs together? I felt confident about this a second ago but then I inspected the thought and I'm not entirely sure how the invalidation logic actually goes, since it would make sense for it to be attemptable usually.

It seems like the target-cpu does not show up in the metadata (or at least I didn’t find it when opening the rmeta file with a text editor).
Linking a library compiled for one target-cpu to a library from another target-cpu works without complaining (it even works when using -Clinker-plugin-lto where lld merges the bitcode files, LLVM doesn’t complain about this).
I guess in many cases this is undesirable (calling a gfx900 function from a gfx1030 function won’t work well), but for some combinations it should be ok (like compiling a library for gfx10-1-generic and using it from a library compiled for gfx1011).

[tgross35]

Maybe this is a case that target modifiers will help prevent?

[rust-log-analyzer]

The job x86_64-gnu-llvm-18 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

#21 exporting to docker image format
#21 sending tarball 28.2s done
#21 DONE 49.7s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-18]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-18', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-18/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10
---
10%  --  54/530,  40 passed, 0 failed, 14 ignored
20%  -- 107/530,  83 passed, 0 failed, 24 ignored
30%  -- 160/530, 128 passed, 0 failed, 32 ignored
40%  -- 213/530, 181 passed, 0 failed, 32 ignored
   [assembly] tests/assembly/targets/targets-amdgpu.rs#amdgcn_amd_amdhsa ... FAILED
60%  -- 319/530, 286 passed, 1 failed, 32 ignored
70%  -- 372/530, 339 passed, 1 failed, 32 ignored
80%  -- 424/530, 391 passed, 1 failed, 32 ignored
90%  -- 477/530, 444 passed, 1 failed, 32 ignored
90%  -- 477/530, 444 passed, 1 failed, 32 ignored
100% -- 530/530, 487 passed, 1 failed, 42 ignored


failures:

---- [assembly] tests/assembly/targets/targets-amdgpu.rs#amdgcn_amd_amdhsa stdout ----

error in revision `amdgcn_amd_amdhsa`: compilation failed!
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/assembly/targets/targets-amdgpu.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--cfg" "amdgcn_amd_amdhsa" "--check-cfg" "cfg(test,FALSE,amdgcn_amd_amdhsa)" "-O" "-Cdebug-assertions=no" "--emit" "asm" "-C" "prefer-dynamic" "-o" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/assembly/targets/targets-amdgpu.amdgcn_amd_amdhsa/targets-amdgpu.s" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target" "amdgcn-amd-amdhsa"
--- stderr -------------------------------
--- stderr -------------------------------
error: target requires explicitly specifying a cpu with `-C target-cpu`
error: aborting due to 1 previous error
------------------------------------------




failures:
    [assembly] tests/assembly/targets/targets-amdgpu.rs#amdgcn_amd_amdhsa
test result: FAILED. 487 passed; 1 failed; 42 ignored; 0 measured; 0 filtered out; finished in 2.27s

Some tests failed in compiletest suite=assembly mode=assembly host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
Build completed unsuccessfully in 0:18:47