Rollup of 6 pull requests#136823
Conversation
Exposes the error function so we can expose this in the standard library [1]. [1]: rust-lang/compiler-builtins#753
We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive
Signed-off-by: onur-ozkan <work@onurozkan.dev>
This fixes an lld warning: > warning: linker stderr: rust-lld: section name .debug_frame is longer > than 8 characters and will use a non-standard string table See https://reviews.llvm.org/D69594 for details of where the warning was added. This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of `x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why. The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld. Tested with: export RUSTC_LOG=rustc_codegen_ssa::back::link=info cargo +stage1 build --release --target i686-unknown-uefi
Signed-off-by: onur-ozkan <work@onurozkan.dev>
…kan,jieyouxu
adding autodiff tests
I'd like to get started with upstreaming some tests, even though I'm still waiting for an answer on how to best integrate the enzyme pass. Can we therefore temporarily support the -Z llvm-plugins here without too much effort? And in that case, how would that work? I saw you can do remapping, e.g. `rust-src-base`, but I don't think that will give me the path to libEnzyme.so. Do you have another suggestion?
Other than that this test simply checks that the derivative of `x*x` is `2.0 * x`, which in this case is computed as
`%0 = fadd fast double %x.0.val, %x.0.val`
(I'll add a few more tests and move it to an autodiff folder if we can use the -Z flag)
r? ``@jieyouxu``
Locally at least `-Zllvm-plugins=${PWD}/build/x86_64-unknown-linux-gnu/enzyme/build/Enzyme/libEnzyme-19.so` seems to work if I copy the command I get from x.py test and run it manually. However, running x.py test itself fails.
Tracking:
- rust-lang#124509
Zulip discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Enzyme.20build.20changes
…imulacrum ci: upgrade to crosstool-ng 1.27.0 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl try-job: dist-powerpc64le-linux
resolve `llvm-config` path properly on cross builds Fixes rust-lang#132926 try-job: x86_64-mingw-2
Update `compiler-builtins` to 0.1.146 Exposes the error function so we can expose this in the standard library [1]. [1]: rust-lang/compiler-builtins#753
…22, r=SparrowLii rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync" rustc_middle: parallel: TyCtxt: remove "unsafe impl DynSend/DynSync" We don't need to "short circuit trait resolution", because DynSend and DynSync are auto traits and thus coinductive cc "Parallel Rustc Front-end" rust-lang#113349 r? SparrowLii ``@rustbot`` label: +WG-compiler-parallel (rustbot sometimes ignores me and doesn't attach labels on my behalf. rustbot banned me?)
…f, r=jieyouxu Disable DWARF in linker options for i686-unknown-uefi This fixes an lld warning: > warning: linker stderr: rust-lld: section name .debug_frame is longer than 8 characters and will use a non-standard string table See https://reviews.llvm.org/D69594 for details of where the warning was added. This warning only occurs with the i686 UEFI target, not x86_64 or aarch64. The x86_64 target uses an LLVM target of `x86_64-unknown-windows` and aarch64 uses `aarch64-unknown-windows`, but i686 uses `i686-unknown-windows-gnu` (note the `-gnu`). See comments in `i686_unknown_uefi.rs` for details of why. The `.debug_frame` section should not actually be needed; UEFI targets provide a separate PDB file for debugging. Disable DWARF (and by extension the `.debug_frame` section) by passing `/DEBUG:NODWARF` to lld. Tested with: ``` export RUSTC_LOG=rustc_codegen_ssa::back::link=info cargo +stage1 build --release --target i686-unknown-uefi ``` This issue was originally raised here: rust-lang#119286 (comment). See also rust-lang#136096. It was suggested to file an LLVM bug, but I don't think LLVM is actually doing anything wrong as such. CC `@dvdhrm` `@jyn514` let me know if you have any feedback on this approach
|
@bors r+ rollup=never p=5 |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 4b293d9927 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (4bb6ec0): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary 3.6%, 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.
CyclesResults (primary 2.3%, secondary -2.2%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 778.713s -> 785.578s (0.88%) |
|
max-rss regressed? |
Successful merges:
llvm-configpath properly on cross builds #136681 (resolvellvm-configpath properly on cross builds)compiler-builtinsto 0.1.146 #136714 (Updatecompiler-builtinsto 0.1.146)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup