-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Autodiff flags #139700
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
ZuseZ4
wants to merge
4
commits into
rust-lang:master
Choose a base branch
from
EnzymeAD:autodiff-flags
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Autodiff flags #139700
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4b475ba
to
0c157e9
Compare
This comment has been minimized.
This comment has been minimized.
oli-obk
reviewed
Apr 15, 2025
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 20, 2025
[DO NOT MERGE] start building enzyme on x86_64-gnu-llvm-{19|20} builders My goal is to put this in CI on April 26, to have a week to land some of the outstanding PRs: rust-lang#139700 rust-lang#139308 rust-lang#139557 rust-lang#140030 rust-lang#140049 The autodiff flags PR should land first, but otherwise they don't overlap and are mostly ready, so it shouldn't be too hard to land them. In the meantime, I'll experiment here with some builders. r? `@oli-obk` Tracking: - rust-lang#124509 try-job: x86_64-gnu-llvm-19 try-job: x86_64-gnu-llvm-20
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 20, 2025
[DO NOT MERGE] start building enzyme on x86_64-gnu-llvm-{19|20} builders My goal is to put this in CI on April 26, to have a week to land some of the outstanding PRs: rust-lang#139700 rust-lang#139308 rust-lang#139557 rust-lang#140030 rust-lang#140049 The autodiff flags PR should land first, but otherwise they don't overlap and are mostly ready, so it shouldn't be too hard to land them. In the meantime, I'll experiment here with some builders. r? `@oli-obk` Tracking: - rust-lang#124509 try-job: dist-x86_64-linux
@bors r+ |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 22, 2025
Autodiff flags Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff. At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes. This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild. It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038) Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem. Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations. r? `@oli-obk` closes rust-lang#139471 Tracking: - rust-lang#124509
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Apr 24, 2025
Autodiff flags Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff. At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes. This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild. It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038) Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem. Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations. r? `@oli-obk` closes rust-lang#139471 Tracking: - rust-lang#124509
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2025
Rollup of 23 pull requests Successful merges: - rust-lang#139261 (mitigate MSVC alignment issue on x86-32) - rust-lang#139307 (std: Add performance warnings to HashMap::get_disjoint_mut) - rust-lang#139700 (Autodiff flags) - rust-lang#139752 (set subsections_via_symbols for ld64 helper sections) - rust-lang#139809 (Don't warn about `v128` in wasm ABI transition) - rust-lang#139852 (StableMIR: Implement `CompilerInterface`) - rust-lang#139945 (Extend HIR to track the source and syntax of a lifetime) - rust-lang#140028 (`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns) - rust-lang#140139 (rustc_target: Adjust RISC-V feature implication) - rust-lang#140143 (Move `sys::pal::os::Env` into `sys::env`) - rust-lang#140148 (CI: use aws codebuild for job dist-arm-linux) - rust-lang#140150 (fix MAX_EXP and MIN_EXP docs) - rust-lang#140172 (Make algebraic functions into `const fn` items.) - rust-lang#140177 ([compiletest] Parallelize test discovery) - rust-lang#140181 (Remove `synstructure::Structure::underscore_const` calls.) - rust-lang#140184 (Update doc of cygwin target) - rust-lang#140186 (Rename `compute_x` methods) - rust-lang#140187 ([AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test) - rust-lang#140191 (Remove git repository from git config) - rust-lang#140194 (minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`) - rust-lang#140195 (triagebot: label minicore changes w/ `A-test-infra-minicore` and ping jieyouxu on changes) - rust-lang#140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/) - rust-lang#140214 (Remove comment about handling non-global where bounds with corresponding projection) r? `@ghost` `@rustbot` modify labels: rollup
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CI-spurious-fail-rust-lld-crash
CI spurious failure: `rust-lld` crashing / SIGSEGV / 0xc0000374 heap corruption
F-autodiff
`#![feature(autodiff)]`
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff.
At least
LLVMRustOptimize
has exactly the flags that we need to disable problematic opt passes.This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild.
It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is not the same as
-Z print-llvm-passes
, which IMHO gives less useful output. A discussion can be found here: #t-compiler/llvm > Print llvm passes. @ 💬Finally, it improves
PrintModBefore
andPrintModAfter
. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the wholedefault<O3>
pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem.Based on the PrintPass output, it also seems like changing
registerEnzymeAndPassPipeline(PB, true);
toregisterEnzymeAndPassPipeline(PB, false);
has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations.r? @oli-obk
closes #139471
Tracking: