Enable the llvm offload build configuration

[ZuseZ4]

Tracking:

• Tracking Issue for GPU-offload #131513

[rustbot]

r? @Kobzol

rustbot has assigned @Kobzol.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ZuseZ4]

argh, I thought the draft state would prevent bors from rolling.
r? @ghost

[rustbot]

Failed to set assignee to ghost: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[ZuseZ4]

r? @Kobzol

Generally, offload is the llvm feature to run code on the GPU and part of my project goal, so this is just the first PR to get warm. Do you want any changes?

This implicitly also enables openmp, since LLVM offload is a feature which developed out of openmp.
It's in some ongoing refactoring so offload is going to work without building openmp in the future, but the build is going to fail of offload is enabled without openmp. I don't think there is a good reason to build rustc with openmp but without offload, so I only have one flag, which people can't get wrong. Are you fine with that?

Edit: updated to include a src/bootstrap/src/utils/change_tracker.rs update.

[rustbot]

This PR modifies src/bootstrap/src/core/config.

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

This PR modifies config.example.toml.

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

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

[bjorn3]

Maybe call it gpu-offload? Or does it also support offloading to other hardware like programmable network controllers and flash drives?

[ZuseZ4]

only compute devices, so no controllers or flash drives, but also non-gpu hardware:
https://clang.llvm.org/docs/OffloadingDesign.html#openmp-offloading

supports [..] target offloading to several different architectures such as NVPTX, AMDGPU, X86_64, Arm, and PowerPC.

But then again GPUs are surely the most popular use-case (though afaik there is a hope to support other coprocessors too).
I don't care strongly for either and for some co-processors like TPUs support we probably want MLIR instead of offload anyway, which would be a follow-up project.

[bors]

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

[ZuseZ4]

ping @Kobzol

[Kobzol]

Oh, this had a conflict and was set to waiting-on-author, so I didn't look at it. Looks fine, please rebase it and I'll approve it.

[ZuseZ4]

@Kobzol Thanks, done.

[Kobzol]

@bors r+

[bors]

📌 Commit e2d3f5a has been approved by Kobzol

It is now in the queue for this repository.

[bors]

⌛ Testing commit e2d3f5a with merge a1d37c2...

[rust-log-analyzer]

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

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

---- [run-make] tests\run-make\avr-rjmp-offset stdout ----

error: rmake recipe failed to complete
status: exit code: 1
command: "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\test\\run-make\\avr-rjmp-offset\\rmake.exe"
--- stderr -------------------------------
command failed at line 29
command failed at line 29
Command { cmd: "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe" "-L" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\test\\run-make\\avr-rjmp-offset\\rmake_out" "avr-rjmp-offsets.rs" "-Copt-level=s" "-Cpanic=abort" "--target=avr-unknown-gnu-atmega328" "-Clinker=rust-lld" "-Clink-arg=--entry=main" "-o" "compiled", stdin_buf: None, stdin: None, stdout: None, stderr: None, drop_bomb: DropBomb { command: "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\stage2\\bin\\rustc.exe", defused: true, armed_location: Location { file: "C:\\a\\rust\\rust\\tests\\run-make\\avr-rjmp-offset\\rmake.rs", line: 16, col: 5 } }, already_executed: true }
output status: `exit code: 1`
=== STDOUT ===


=== STDERR ===
error: linking with `rust-lld` failed: exit code: 0xc0000374
error: linking with `rust-lld` failed: exit code: 0xc0000374
  |
  = note: "rust-lld" "-flavor" "gnu" "C:\\a\\_temp\\msys64\\tmp\\rustc4vG81h\\symbols.o" "compiled.avr_rjmp_offsets.ab053966543a1f9f-cgu.0.rcgu.o" "--as-needed" "-Bdynamic" "-z" "noexecstack" "-L" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-gnu\\test\\run-make\\avr-rjmp-offset\\rmake_out" "-o" "compiled" "--gc-sections" "--entry=main"

error: aborting due to 1 previous error
------------------------------------------

[bors]

💔 Test failed - checks-actions

[Kobzol]

That looks.. spurious, but also concerning (heap corruption error?). Let's retry.

@bors retry

[bors]

⌛ Testing commit e2d3f5a with merge 17f8215...

[bors]

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing 17f8215 to master...

[rust-timer]

Finished benchmarking commit (17f8215): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[0.4%, 0.4%]	1

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 782.08s -> 784.653s (0.33%)
Artifact size: 333.70 MiB -> 333.81 MiB (0.03%)