-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
Rollup of 5 pull requests #151533
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 5 pull requests #151533
Conversation
This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64. When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB. This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
There are a number of instances of `FIXME(f16_f128)` related to target configuration; either these could use `target_has_reliable_f128`, or the FIXME is describing such a cfg and is thus redundant (since any `cfg(target_has_reliable_f*)` needs to be removed before stabilization anyway). Switch to using `target_has_reliable_*` where applicable and remove the redundant FIXMEs.
This FIXME was introduced in 6e2d934 ("Add more `f16` and `f128` library functions and constants") but I can't actually find my reasoning. As far as I can tell, LLVM has been lowering `fabs.f128` as bitwise operations for a while across all targets so there shouldn't be a problem here. Thus, apply what is suggested in the FIXME.
…6,f128` Make it easier to identify which FIXMEs are blocking stabilization of which type.
…h726 inline constant localized typeck constraint computation This fixes an oversight in the previous PRs, this constraint is local to a point (and liveness does the rest) and so has a fixed direction. I wasn't planning on trying to improve the impl for perf, versus computing loan liveness without first unifying the cfg and subset graph, but it's like a 20x improvement for typeck constraints on wg-grammar (-15% end-to-end) for a trivial fix. r? @jackh726 In general, I want to cleanup these edges to avoid off-by-one errors in constraints at effectful statements and ensure the midpoint-avoidance strategy is sound and works well, in particular with respect to edges that flow backwards from the result into its inputs. But I'd like to start from something that passes all tests and is simpler, because the eventual solution may 1. involve localizing these edges differently than *separate* liveness and typeck lowering passes/approaches, which would need to be lowered at the same time for example. I'm already doing the latter in the loan liveness rewrite as part of creating edges on-demand during traversal, and this new structure would be a better fit to verify, or fix, these subtle edges. 2. also require changes in MIR typeck to track the flow across points more precisely, and I don't know how hard that would be. *Computing* the constraint direction is currently a workaround for that. Therefore, in a future PR, I'll also remove this computation from the terminator constraints, but I can also do that in this PR if you'd prefer.
…d, r=jackh726 Add -Z large-data-threshold This flag allows specifying the threshold size for placing static data in large data sections when using the medium code model on x86-64. When using -Ccode-model=medium, data smaller than this threshold uses RIP-relative addressing (32-bit offsets), while larger data uses absolute 64-bit addressing. This allows the compiler to generate more efficient code for smaller data while still supporting data larger than 2GB. This mirrors the -mlarge-data-threshold flag available in GCC and Clang. The default threshold is 65536 bytes (64KB) if not specified, matching LLVM's default behavior.
…ivooeo Rename `HandleCycleError` to `CycleErrorHandling` In rust-lang#101303, the `handle_cycle_error` field was changed from a macro-generated closure to a macro-selected enum variant. But it was not renamed to reflect the fact that it now holds data, not code. Renaming the field and its associated enum to `cycle_error_handling: CycleErrorHandling` should make the relevant code less confusing to read. This PR also moves the enum out of `rustc_query_system::error`, where it was easily confused with diagnostic structs. There should be no change to compiler behaviour.
update enzyme, includes an extra patch to fix MacOS builds in CI I updated the submodule under rust-lang/enzyme to match EnzymeAD/enzyme, and added one commit, which based on some testing should fix how we build Enzyme in the MacOS CI. Once this pr landed, we will verify again that CI still works, and afterwards upstream the patch and drop it from our fork. No new test failures. cc @sgasho r? @Kobzol
…ertdev Clean up or resolve cfg-related instances of `FIXME(f16_f128)` * Replace target-specific config that has a `FIXME` with `cfg(target_has_reliable_f*)` * Take care of trivial intrinsic-related FIXMEs * Split `FIXME(f16_f128)` into `FIXME(f16)`, `FIXME(f128)`, or `FIXME(f16,f128)` to more clearly identify what they block The individual commit messages have more details.
|
@bors r+ rollup=never p=5 |
This comment has been minimized.
This comment has been minimized.
|
📌 Perf builds for each rolled up PR:
previous master: 9283d592de In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 9283d59 (parent) -> 5944b12 (this PR) Test differencesShow 364 test diffsStage 1
Stage 2
Additionally, 360 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 5944b12bd4cca78d0c32aa67b501af3e1aefd1a9 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (5944b12): 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 1.3%, secondary -6.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.0%, secondary -2.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 471.36s -> 474.479s (0.66%) |
Successful merges:
HandleCycleErrortoCycleErrorHandling#151520 (RenameHandleCycleErrortoCycleErrorHandling)FIXME(f16_f128)#151527 (Clean up or resolve cfg-related instances ofFIXME(f16_f128))r? @ghost
Create a similar rollup