improvements towards building enzyme in CI

[ZuseZ4]

1. This PR fixes a significant compile-time regression, by only running the expensive autodiff pipeline, if the users pass the newly introduced Enable value to the -Zautodiff= flag. It updates the test(s) accordingly. It gives a nice error if users forget that.
2. It fixes macos support by explicitly linking against the Enzyme build folder. This doesn't cover CI macos yet.
3. It fixes the issue that setting ENZYME_RUNPASS was ignored by enzyme and in fact did not schedule enzyme's opt pass.
4. It also re-enables support for various other values for the autodiff flag, which were ignored since the refactor.
5. I merged some improvements to Enzyme core, which means we do not longer depend on LLVM being build with the Plugin Interface enabled.
6. Unrelated to other fixes, this changes rustc_autodiff to EncodeCrossCrate::Yes. It is not enough on it's own to enable usage of Enzyme in libraries, but it is for sure a piece of the fixes needed to get this to work.

try-job: x86_64-gnu

r? @oli-obk

Tracking:

• Tracking Issue for autodiff #124509

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

[rustbot]

This PR modifies config.example.toml.

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

[ZuseZ4]

ok rustbot, thanks for your opinion. I will however wtick with r? @oli-obk

[lqd]

CI doesn't use config.example.toml. As you can see in the file, this is all commented out values explaining the defaults of these attributes. It is a base people use to create a new config file if you don't have one.

[ZuseZ4]

Yes I know how they work, I just assumed that one of the ci runners would use a configure command which doesn't explicitly sets enzyme, and then the change would have worked. So I guess I have to look into one of the build scritps instead :/

[Kobzol]

You have to select a CI job where you want the tests to run and then configure it to enable these config.toml options, using e.g. --set (

rust/src/ci/docker/host-x86_64/x86_64-gnu-llvm-18/Dockerfile

Line 55 in 9ba34f8

--set rust.thin-lto-import-instr-limit=10

).

[ZuseZ4]

Thanks. I want one of the builders which compiles the src/llvm-project llvm, and does not reuse an existing one. It looks like this is one of them, correct?

[workingjubilee]

@bors try

[bors]

⌛ Trying commit f15f626 with merge cd73423...

[bors]

☀️ Try build successful - checks-actions
Build commit: cd73423 (cd73423831e5185936e5f5f6d8dcfd4d9f400836)

[tgross35]

@rust-timer queue

[tgross35]

Whoops

@rust-timer build cd73423

[rust-timer]

Finished benchmarking commit (cd73423): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +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)	1.6%	[0.3%, 3.2%]	230
Regressions ❌ (secondary)	1.3%	[0.2%, 2.6%]	197
Improvements ✅ (primary)	-2.8%	[-9.3%, -0.4%]	40
Improvements ✅ (secondary)	-5.2%	[-15.6%, -0.7%]	7
All ❌✅ (primary)	0.9%	[-9.3%, 3.2%]	270

Max RSS (memory usage)

Results (primary -3.5%, secondary -2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.1%	[0.7%, 2.0%]	5
Improvements ✅ (primary)	-3.5%	[-3.7%, -3.4%]	2
Improvements ✅ (secondary)	-3.2%	[-6.3%, -1.3%]	13
All ❌✅ (primary)	-3.5%	[-3.7%, -3.4%]	2

Cycles

Results (primary -1.1%, secondary -3.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.3%	[0.8%, 1.7%]	30
Regressions ❌ (secondary)	1.6%	[1.6%, 1.7%]	2
Improvements ✅ (primary)	-3.2%	[-8.3%, -1.0%]	34
Improvements ✅ (secondary)	-4.6%	[-10.9%, -1.2%]	6
All ❌✅ (primary)	-1.1%	[-8.3%, 1.7%]	64

Binary size

Results (primary -1.0%, secondary -2.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-2.8%, -0.1%]	70
Improvements ✅ (secondary)	-2.3%	[-3.5%, -0.7%]	76
All ❌✅ (primary)	-1.0%	[-2.8%, -0.1%]	70

Bootstrap: 777.802s -> 763.65s (-1.82%)
Artifact size: 328.69 MiB -> 322.91 MiB (-1.76%)

[Kobzol]

This builder does build LLVM (like 5 times xD), but it does not really run normal tests, so it's not a good fit.

Now, why the hell does enabling LLVM plugins improve bootstrap time and reduce compiler binary size, wtf.

[ZuseZ4]

I noticed 3 and was already wondering.
Do you have suggestions for a better build? It should be one which builds src/llvm

[Kobzol]

I would say x86_64-gnu.

[bors]

💔 Test failed - checks-actions

[ZuseZ4]

cc @saethlin
https://github.com/rust-lang/rust/pull/136428/files#diff-37e9c44cff55695f4c7497a9eba475172f70c46dfb3a6741a0adc6ca40071c59
and
https://github.com/rust-lang/rust/pull/136428/files#diff-eac3d5ef63f39b7914ae9015f31b8d87353ea8fbcd5b02a7335dd86c557e7625
Add some new things to link against. It looks like you only care about me linking against LLVM and not Enzyme, so probably they don't need annotations? But I thought I ping you to be sure.

[saethlin]

Don't worry about making the compiler build with -Zcross-crate-inline-threshold=always, I'll just fix it after the fact if it breaks :)

[ZuseZ4]

@oli-obk This is ready to be merged, let me know if you want any changes.

quickly testing a build from scratch, I think due to the LLVM upgrade I had some stale artifacts.

Edit2: I can confirm that my issues where only due to having LLVM19 and LLVM20 in the same build folder, since I rebased the final PR and the artifacts got mixed up by bootstrap. Deleting the build dir and starting a clean build fixed all issues.

So this is indeed ready to merge.

[oli-obk]

@bors r+

[bors]

📌 Commit 49e9630 has been approved by oli-obk

It is now in the queue for this repository.

[bors]

⌛ Testing commit 49e9630 with merge 8dac72b...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 8dac72b to master...

[Kobzol]

This PR didn't actually start testing Enzyme on CI, right? So the PR title should be updated.

[rust-timer]

Finished benchmarking commit (8dac72b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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: 773.139s -> 773.405s (0.03%)
Artifact size: 361.03 MiB -> 361.04 MiB (0.00%)