-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
fix: alloc-optimisation is only for rust llvm #89591
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
CC @Amanieu |
Another related question would be, could it actually just be pushed into upstream LLVM itself, perhaps generalised for them to make the choice of function name configurable. |
There was a thread on Zulip about upstreaming the LLVM patch for |
@bors r+ rollup |
📌 Commit b386959 has been approved by |
…arth Rollup of 12 pull requests Successful merges: - rust-lang#87601 (Add functions to add unsigned and signed integers) - rust-lang#88523 (Expand documentation for `FpCategory`.) - rust-lang#89050 (refactor: VecDeques Drain fields to private) - rust-lang#89245 (refactor: make VecDeque's IterMut fields module-private, not just crate-private) - rust-lang#89324 (Rename `std::thread::available_conccurrency` to `std::thread::available_parallelism`) - rust-lang#89329 (print-type-sizes: skip field printing for primitives) - rust-lang#89501 (Note specific regions involved in 'borrowed data escapes' error) - rust-lang#89506 (librustdoc: Use correct heading levels.) - rust-lang#89528 (Fix suggestion to borrow when casting from pointer to reference) - rust-lang#89531 (library std, libc dependency update) - rust-lang#89588 (Add a test for generic_const_exprs) - rust-lang#89591 (fix: alloc-optimisation is only for rust llvm) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As discussed at the bottom of #83485.
On a separate note I'll take this chance ask, is it worth pulling in that patch (to recognise
__rust_dealloc
) into Debian's system LLVM? The main factors for us to consider would be (1) is the optimisation significant and (2) is there not any significant negative impact to non-rust packages that use LLVM.