-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rollup of 8 pull requests #140256
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 8 pull requests #140256
Conversation
This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective. The main rule is: If the feature A is a functional superset of the feature B (A ⊃ B), A is to imply B, even if this implication is not on the manual. Such implications (not directly referred in the ISA manual) are commented as "A ⊃ B" which means "A is a (functional) superset of B". 1. Zbc → Zbkc (add as a superset) The Zbkc extension is a subset of the Zbc extension (Zbc - "clmulr" instruction == Zbkc) 2. Zkr → (nothing) (remove dependency to Zicsr) Implication to the Zicsr extension is removed because (although nearly harmless), the Zkr extension (or the "seed" CSR section) defines its own subset of the Zicsr extension. 3. Zvbb → Zvkb (comment as a superset) This implication was already there but not denoted as a functional superset. This commit adds the comment. 4. Zvfh → Zvfhmin (comment as a superset) This is similar to the case above (Zvbb → Zvkb). 5. Zvfh → Zve32f (add implication per the ISA specification) This dependency is on the ISA manual but was missing (due to the fact that Zvfh indirectly implies Zve32f on the current implementation through Zvfh → Zvfhmin, which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though). 6. Zvknhb → Zvknha (add as a superset) The Zvknhb extension (SHA-256 / SHA-512) is a functional superset of the Zvknha extension (SHA-256 only).
I missed this in rust-lang#139868. Its `mod` declaration was removed, but the contents were not moved.
…ions of 'f16', 'f32', 'f64', and 'f128' into 'const fn' items;
It is no longer needed after a recent refactoring.
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc implements rust-lang#136067 Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases. ```rs fn bytes_at_home(x: [u8; 4]) -> u32 { transmute(x) } // other examples transmute::<[u8; 2], u16>(); transmute::<[u8; 8], f64>(); transmute::<u32, [u8; 4]>(); transmute::<char, u32>(); transmute::<u32, char>(); ``` It would be handy to suggest `u32::from_ne_bytes(x)`. This is implemented for `[u8; _]` -> `{float int}` This also implements the cases: `fXX` <-> `uXX` = `{from_bits, to_bits}` `uXX` -> `iXX` via `cast_unsigned` and `cast_signed` {`char` -> `u32`, `bool` -> `n8`} via `from` `u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested) `u8` -> `bool` via `==` (debatable) --- try-job: aarch64-gnu try-job: test-various
…li-obk Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions` This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge rust-lang#137306 then this can be reverted. Tracking issue: rust-lang#56071
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
… r=Amanieu rustc_target: Adjust RISC-V feature implication This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective. The main rule is: * If the feature `A` is a functional superset of the feature `B` (`A ⊃ B`), `A` is to imply `B`, even if this implication is not on the manual. Such implications (not directly written in the ISA manual) are commented as `A ⊃ B` which means "`A` is a (functional) superset of `B`". 1. `Zbc` → `Zbkc` (add as a superset) The `Zbkc` extension is a subset of the `Zbc` extension (`Zbc` minus `clmulr` instruction). 2. `Zkr` → (nothing) (remove dependency to `Zicsr`) Implication to the `Zicsr` extension is removed because (although nearly harmless), the `Zkr` extension (or the `seed` CSR section) defines its own subset of the `Zicsr` extension (guaranteed to work against the `seed` CSR which needs read/write access). 3. `Zvbb` → `Zvkb` (comment as a superset) This implication was already there but not denoted as a functional superset. This commit adds the comment. 4. `Zvfh` → `Zvfhmin` (comment as a superset) This is similar to the case above (`Zvbb` → `Zvkb`). 5. `Zvfh` → `Zve32f` (add implication per the ISA specification) This dependency is on the ISA manual but was missing (due to the fact that `Zvfh` indirectly implies `Zve32f` on the current implementation through `Zvfh` → `Zvfhmin` which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though). 6. `Zvknhb` → `Zvknha` (add as a superset) The `Zvknhb` extension (SHA-256 / SHA-512) is a functional superset of the `Zvknha` extension (SHA-256 only).
Move zkVM constants into `sys::env_consts` I missed this in rust-lang#139868. Its `mod` declaration was removed, but the contents were not moved. r? joboet
fix MAX_EXP and MIN_EXP docs As pointed out in rust-lang#88734, the docs for these constants are wrong. r? ``@tgross35``
…r=RalfJung Make algebraic functions into `const fn` items. Tracking issue: rust-lang#136469 This PR makes the algebraic intrinsics and the unstable, algebraic functions of `f16`, `f32`, `f64`, and `f128` into `const fn` items: ```rust impl f16 { pub const fn algebraic_add(self, rhs: f16) -> f16; pub const fn algebraic_sub(self, rhs: f16) -> f16; pub const fn algebraic_mul(self, rhs: f16) -> f16; pub const fn algebraic_div(self, rhs: f16) -> f16; pub const fn algebraic_rem(self, rhs: f16) -> f16; } impl f32 { pub const fn algebraic_add(self, rhs: f32) -> f32; pub const fn algebraic_sub(self, rhs: f32) -> f32; pub const fn algebraic_mul(self, rhs: f32) -> f32; pub const fn algebraic_div(self, rhs: f32) -> f32; pub const fn algebraic_rem(self, rhs: f32) -> f32; } impl f64 { pub const fn algebraic_add(self, rhs: f64) -> f64; pub const fn algebraic_sub(self, rhs: f64) -> f64; pub const fn algebraic_mul(self, rhs: f64) -> f64; pub const fn algebraic_div(self, rhs: f64) -> f64; pub const fn algebraic_rem(self, rhs: f64) -> f64; } impl f128 { pub const fn algebraic_add(self, rhs: f128) -> f128; pub const fn algebraic_sub(self, rhs: f128) -> f128; pub const fn algebraic_mul(self, rhs: f128) -> f128; pub const fn algebraic_div(self, rhs: f128) -> f128; pub const fn algebraic_rem(self, rhs: f128) -> f128; } // core::intrinsics pub const fn fadd_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fsub_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fmul_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn fdiv_algebraic<T: Copy>(a: T, b: T) -> T; pub const fn frem_algebraic<T: Copy>(a: T, b: T) -> T; ``` This PR does not preserve the initial behaviour of these functions yielding non-deterministic output under Miri; it is most likely desired to reimplement this behaviour at some point.
…git-config, r=jieyouxu Remove git repository from git config It is no longer needed after rust-lang#138591. We could even remove the `nightly_branch` field, but it still has one usage. r? ``@jieyouxu``
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 3c877f6 (parent) -> d7ea436 (this PR) Test differencesShow 1211 test diffsStage 1
Stage 2
Additionally, 1207 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard d7ea436a02d5de4033fcf7fd4eb8ed965d0f574c --output-dir test-dashboard And then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
📌 Perf builds for each rolled up PR:
previous master: 3c877f6a47 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (d7ea436): comparison URL. Overall result: ❌✅ regressions and improvements - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 0.5%, secondary 0.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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 777.873s -> 777.966s (0.01%) |
Successful merges:
#[repr(u128)]
/#[repr(i128)]
enums toimproper_ctypes_definitions
#138282 (Add#[repr(u128)]
/#[repr(i128)]
enums toimproper_ctypes_definitions
)sys::env_consts
#140141 (Move zkVM constants intosys::env_consts
)const fn
items. #140172 (Make algebraic functions intoconst fn
items.)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup