Tracking Issue for amdgpu target #135024

Flakebi · 2025-01-02T14:18:41Z

…=compiler-errors Remove range-metadata amdgpu workaround Range metadata was disabled for amdgpu due to a backend bug. I did not encounter any problems when removing the workaround to enable range metadata (tried compiling `core` and `alloc`), so I assume this has been fixed in LLVM in the last years. Remove the workaround to re-enable range metadata. Tracking issue: rust-lang#135024

Rollup merge of rust-lang#135027 - Flakebi:remove-range-workaround, r=compiler-errors Remove range-metadata amdgpu workaround Range metadata was disabled for amdgpu due to a backend bug. I did not encounter any problems when removing the workaround to enable range metadata (tried compiling `core` and `alloc`), so I assume this has been fixed in LLVM in the last years. Remove the workaround to re-enable range metadata. Tracking issue: rust-lang#135024

…gjubilee Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e9 (rust-lang#120495 and rust-lang/rust-analyzer#16463) due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for. Tracking issue: rust-lang#135467 amdgpu target tracking issue: rust-lang#135024

…ubilee Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e9 (rust-lang#120495 and rust-lang/rust-analyzer#16463) due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for. Tracking issue: rust-lang#135467 amdgpu target tracking issue: rust-lang#135024

Cast global variables to default address space Pointers for variables all need to be in the same address space for correct compilation. Therefore ensure that even if a global variable is created in a different address space, it is casted to the default address space before its value is used. This is necessary for the amdgpu target and others where the default address space for global variables is not 0. For example `core` does not compile in debug mode when not casting the address space to the default one because it tries to emit the following (simplified) LLVM IR, containing a type mismatch: ```llvm `@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1 `@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspace(1) `@alloc_0` }>, align 8 ; ^ here a struct containing a `ptr` is needed, but it is created using a `ptr addrspace(1)` ``` For this to compile, we need to insert a constant `addrspacecast` before we use a global variable: ```llvm `@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1 `@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspacecast (ptr addrspace(1) `@alloc_0` to ptr) }>, align 8 ``` As vtables are global variables as well, they are also created with an `addrspacecast`. In the SSA backend, after a vtable global is created, metadata is added to it. To add metadata, we need the non-casted global variable. Therefore we strip away an addrspacecast if there is one, to get the underlying global. Tracking issue: rust-lang#135024

Target option to require explicit cpu Some targets have many different CPUs and no generic CPU that can be used as a default. For these targets, the user needs to explicitly specify a CPU through `-C target-cpu=`. Add an option for targets and an error message if no CPU is set. This affects the proposed amdgpu and avr targets. amdgpu tracking issue: rust-lang#135024 AVR MCP: rust-lang/compiler-team#800

Rollup merge of rust-lang#135026 - Flakebi:global-addrspace, r=saethlin Cast global variables to default address space Pointers for variables all need to be in the same address space for correct compilation. Therefore ensure that even if a global variable is created in a different address space, it is casted to the default address space before its value is used. This is necessary for the amdgpu target and others where the default address space for global variables is not 0. For example `core` does not compile in debug mode when not casting the address space to the default one because it tries to emit the following (simplified) LLVM IR, containing a type mismatch: ```llvm `@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1 `@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspace(1) `@alloc_0` }>, align 8 ; ^ here a struct containing a `ptr` is needed, but it is created using a `ptr addrspace(1)` ``` For this to compile, we need to insert a constant `addrspacecast` before we use a global variable: ```llvm `@alloc_0` = addrspace(1) constant <{ [6 x i8] }> <{ [6 x i8] c"bit.rs" }>, align 1 `@alloc_1` = addrspace(1) constant <{ ptr }> <{ ptr addrspacecast (ptr addrspace(1) `@alloc_0` to ptr) }>, align 8 ``` As vtables are global variables as well, they are also created with an `addrspacecast`. In the SSA backend, after a vtable global is created, metadata is added to it. To add metadata, we need the non-casted global variable. Therefore we strip away an addrspacecast if there is one, to get the underlying global. Tracking issue: rust-lang#135024

…bilee Add amdgpu target 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: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while).

Add amdgpu target 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: rust-lang#135024 Kinda related to the original amdgpu tracking issue rust-lang#51575 (though that one has been closed for a while). try-job: dist-powerpc-linux try-job: dist-powerpc64-linux try-job: dist-powerpc64le-linux try-job: dist-various-1 try-job: dist-various-2 try-job: aarch64-gnu

Flakebi added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jan 2, 2025

This was referenced Jan 2, 2025

Add gpu-kernel calling convention #135047

Merged

Add amdgpu target rust-lang/compiler-team#823

Closed

Flakebi mentioned this issue Jan 13, 2025

Add amdgpu target to ecosystem page Rust-GPU/rust-gpu.github.io#59

Open

workingjubilee added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. O-amdgpu AMDGPU targets A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. labels Jan 14, 2025

Flakebi mentioned this issue Jan 23, 2025

Export kernel descriptor for amdgpu kernels #135909

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for amdgpu target #135024

Tracking Issue for amdgpu target #135024

Flakebi commented Jan 2, 2025 •

edited

Loading

Tracking Issue for amdgpu target #135024

Tracking Issue for amdgpu target #135024

Comments

Flakebi commented Jan 2, 2025 • edited Loading

Implementation

Bugs

Flakebi commented Jan 2, 2025 •

edited

Loading