Cleanup offload datatransfer #151640

ZuseZ4 · 2026-01-25T08:50:51Z

There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back.
At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage.

cc @jdoerfert @kevinsala

r? compiler

tests/codegen-llvm/gpu_offload/gpu_host.rs

ZuseZ4 · 2026-01-26T14:52:33Z

I don't think jieyouxu will want to review this part of rustc.
r? @oli-obk

rustbot · 2026-01-26T14:52:38Z

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

ZuseZ4 · 2026-02-02T00:42:56Z

@rustbot reroll

rustbot · 2026-02-06T20:36:29Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

compiler/rustc_codegen_llvm/src/builder/gpu_offload.rs

Zalathar · 2026-02-07T13:13:54Z

The individual commits seem like they don't have a reason to be separate, so please squash them.

ZuseZ4 · 2026-02-08T01:05:02Z

One of the commits had gotten lost over one of the last rebases. I've re-added it and fused them.

compiler/rustc_codegen_llvm/src/builder/gpu_offload.rs

nnethercote · 2026-02-08T01:14:41Z

r=me, just one question about the subset operation above.

…t_all_rtls into global ctor

ZuseZ4 · 2026-02-08T07:14:02Z

@bors r=nnethercote rollup

rust-bors · 2026-02-08T07:14:05Z

📌 Commit 6de0591 has been approved by nnethercote

It is now in the queue for this repository.

@jdoerfert

…thercote Cleanup offload datatransfer There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back. At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage. cc @jdoerfert @kevinsala r? compiler

@jdoerfert

…thercote Cleanup offload datatransfer There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back. At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage. cc @jdoerfert @kevinsala r? compiler

@jdoerfert

…thercote Cleanup offload datatransfer There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back. At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage. cc @jdoerfert @kevinsala r? compiler

…uwer Rollup of 7 pull requests Successful merges: - #151455 (Fix `SourceFile::normalized_byte_pos`) - #152250 (Remove support for slugs in diagnostic messages) - #152322 (Replace some `feature(core_intrinsics)` with stable hints) - #152328 (Fix a few diagnostics) - #151640 (Cleanup offload datatransfer) - #152212 (Port some attributes to the attr parser) - #152309 (Fix bound var resolution for trait aliases)

@jdoerfert

…thercote Cleanup offload datatransfer There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back. At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage. cc @jdoerfert @kevinsala r? compiler

…uwer Rollup of 8 pull requests Successful merges: - #151455 (Fix `SourceFile::normalized_byte_pos`) - #152250 (Remove support for slugs in diagnostic messages) - #152322 (Replace some `feature(core_intrinsics)` with stable hints) - #151640 (Cleanup offload datatransfer) - #152212 (Port some attributes to the attr parser) - #152309 (Fix bound var resolution for trait aliases) - #152339 (diagnostics: fix ICE in closure signature mismatch) - #152341 (`cfg_select!`: allow optional comma after `{ /* ... */ }`)

…uwer Rollup of 9 pull requests Successful merges: - #151455 (Fix `SourceFile::normalized_byte_pos`) - #152250 (Remove support for slugs in diagnostic messages) - #152322 (Replace some `feature(core_intrinsics)` with stable hints) - #152328 (Fix a few diagnostics) - #151640 (Cleanup offload datatransfer) - #152212 (Port some attributes to the attr parser) - #152309 (Fix bound var resolution for trait aliases) - #152339 (diagnostics: fix ICE in closure signature mismatch) - #152341 (`cfg_select!`: allow optional comma after `{ /* ... */ }`)

@jdoerfert

Rollup merge of #151640 - ZuseZ4:cleanup-datatransfer, r=nnethercote Cleanup offload datatransfer There are 3 steps to run code on a GPU: Copy data from the host to the device, launch the kernel, and move it back. At the moment, we have a single variable describing the memory handling to do in each step, but that makes it hard for LLVM's opt pass to understand what's going on. We therefore split it into three variables, each only including the bits relevant for the corresponding stage. cc @jdoerfert @kevinsala r? compiler

ZuseZ4 added the F-gpu_offload `#![feature(gpu_offload)]` label Jan 25, 2026