-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Rollup of 6 pull requests #136823
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 <[email protected]>
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 <[email protected]>
…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-config
path properly on cross builds #136681 (resolvellvm-config
path properly on cross builds)compiler-builtins
to 0.1.146 #136714 (Updatecompiler-builtins
to 0.1.146)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup