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.

[matthiaskrgr]

@bors rollup=never

[workingjubilee]

This is blocking other related PRs from proceeding, so

@bors p=1

[workingjubilee]

Reason for the rollup=never:

@klensy in #136399 (comment):

#134740 adds llvm target, probably increasing libllvm size, should be rollup=never?

@matthiaskrgr in #136399 (comment):

maybe we need exponentially more memory during lto or something with the new target...

if've iffyd #136309 and never'd #134740 let's see if that help..

notable though that none of the other rollup=never prs have landed in the meantime, maybe gh is just having a bad weekend :/

I think that's unlikely, but LLVM does love to randomly have a runaway compile time event, so "unlikely" is certainly not "extremely unlikely" and it's probably just as well.

[workingjubilee]

Also, if this is suspected of being the reason for failures of rollups, it should just be put through a try-job anyways, since we have enough high-risk jobs in the queue already, we don't need to send something through with only middling confidence it will work:

@bors r-
@bors try

[bors]

⌛ Trying commit 56795fb with merge 6faa3e6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6faa3e6 (6faa3e6fd2949d5cb421d19522f597501fc751a7)

[saethlin]

@bors r=workingjubilee

[bors]

📌 Commit 56795fb has been approved by workingjubilee

It is now in the queue for this repository.