ci: Enable autodiff tests on x86_64 linux

[sgasho]

View all comments

Enable autodiff tests on x86_64 linux

hmm.....pr job x stage 1 takes 100 - 110min, which is the slowest in the pr jobs.
If we are not happy to wait more than 100min for the pr jobs, maybe we should move this to auto jobs and test them on stage 2

r? @ZuseZ4

[sgasho]

I executed git pull --rebase origin main to see if build steps in autodiff job finish successfully after enzyme submodule update

No problem found

[rustbot]

Warning

If you are changing how CI LLVM is built or linked, make sure to bump
src/bootstrap/download-ci-llvm-stamp.

cc @jieyouxu

[ZuseZ4]

@bors try jobs=x86_64-gnu-autodiff

Rerunning to test potential cache effects.
Once this is done, we should ping Jakub and jieyouxu to discuss where to put it (and probably create an infra thread to discuss). I also don't think they'll accept autodiff as a culprit of measurably longer PR CI, so we'll probably need to move it, if the cache isn't helping enough.

[rust-bors]

☀️ Try build successful (CI)
Build commit: d1a9718 (d1a971826b83fead3b7550c5e4440c9102bb3290)
Base parent: 3c00c96 (3c00c96d3af4d5b5e101e56cc161a608b21366ee)

[ZuseZ4]

Rebuilding a second time, since I'm not sure if artifacts are shared between PR Ci and try runs.
@bors try jobs=x86_64-gnu-autodiff

But so far, even just building LLVM+rustc+std+enzyme takes 95 minutes, 10 minutes more than miri, the next slowest job. Total time will always be a bit more than that, and autodiff will always have less users than something general like Miri, so that's hard to defend.

If the try results come back unchanged, can you move it to auto and mark it as allowed to fail? I don't think it needs to be blocking yet.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 96310de (96310dea88820c3264b54ee2b5011698005372aa)
Base parent: 36714a9 (36714a9983d6ba11203d8bb87a1b372247fbcf06)

[ZuseZ4]

submodule updates are meant to be trivial so those not breaking us doesn't mean much. There's an open update to llvm23, can you test if that breaks something?

But I generally wouldn't want to block this on an MCP and (for now) I'd rather like us to chase optional CI failures since that's up to us, rather than pushing bugfixes onto other people, at least for now.

[rustbot]

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.

[rustbot]

Some changes occurred in src/tools/enzyme

cc @ZuseZ4

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

Some changes occurred in coverage tests.

cc @Zalathar

rustc_codegen_cranelift is developed in its own repository. If possible, consider making this change to rust-lang/rustc_codegen_cranelift instead.

cc @bjorn3

[rustbot]

⚠️ Warning ⚠️

• Some commits in this PR modify submodules.

  If this was not intentional, see I changed a submodule on accident in the rustc dev guide.

• The following commits have merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

  • 37dc58b

  You can start a rebase with the following commands:

  $ # rebase
  $ git pull --rebase https://github.com/rust-lang/rust.git main
  $ git push --force-with-lease
  

[sgasho]

@bors try jobs=optional-x86_64-gnu-autodiff

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1d0455a (1d0455a9c97b86ae095c59bec7ef269ff1a58886)
Base parent: 4a9d536 (4a9d5368df6450bbd2fc8dde4508c3e5d83bb19d)

[rust-bors]

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