rust/compiler/rustc_codegen_llvm/src/builder, branch try

gpu host code generation

2025-07-18T23:30:42+00:00

Rollup merge of #143388 - bjorn3:lto_refactors, r=compiler-errors

2025-07-17T01:58:28+00:00

Various refactors to the LTO handling code In particular reducing the sharing of code paths between fat and thin-LTO and making the fat LTO implementation more self-contained. This also moves some autodiff handling out of cg_ssa into cg_llvm given that Enzyme only works with LLVM anyway and an implementation for another backend may do things entirely differently. This will also make it a bit easier to split LTO handling out of the coordinator thread main loop into a separate loop, which should reduce the complexity of the coordinator thread.

Eliminate all direct uses of LLVMMDStringInContext2

2025-07-14T08:27:08+00:00

Merge `typeid_metadata` and `create_metadata`

2025-07-14T08:27:08+00:00

Make some "safe" llvm ops actually sound

2025-07-10T07:27:41+00:00

Remove unused config param from WriteBackendMethods::autodiff

2025-07-03T16:13:25+00:00

add and use generic get_const_int function

2025-06-16T21:23:06+00:00

add custom enzyme markers to target methods

2025-04-25T05:39:52+00:00

Rollup merge of #139700 - EnzymeAD:autodiff-flags, r=oli-obk

2025-04-24T15:19:44+00:00

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` 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 #139471 Tracking: - https://github.com/rust-lang/rust/issues/124509

working dupv and dupvonly for fwd mode

2025-04-16T21:13:31+00:00