-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Inline Box drop glue #46638
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Inline Box drop glue #46638
Conversation
Box<T> drop glue is pretty simple and should not lead to blow-up problems. Moreover, not inlining it leads to LLVM pessimizing some pointer-based optimizations because it thinks the pointer passed to the drop glue could be escaped. Fixes rust-lang#46515. However, this is not a great fix -- the problem still exists for other smart pointers besides `Box`.
(rust_highfive has picked a reviewer for you, use r? to override) |
Also, I'd like to add a codegen test for this -- how would I go about that? |
Have you verified if this will regress in #41696? |
I tried the test at #41696 (comment), and it still completes pretty much instantaneously even with Some codegen tests fail with this PR; I don't understand their syntax and what exactly they are checking very well. |
It's unsurprising that this doesn't impact the test case from #41696 (comment) since that code doesn't involve |
This PR only improves the situation with |
Yeah... mostly I wrote this to confirm that this is indeed what's causing #46515. I was going to change it to fire any time the top-level type is |
There is nothing subtle going on here - this just feels like a hack that is going to stay for quite some time without improving any real code. |
Do you think it is useful to try and develop a heuristic for this? Like, look at the type and allow inlining for the destructor if there are less than N nested drops? Otherwise, I'm fine closing this. |
I think developing an heuristic would be an interesting project but would require some work to actually help real-world cases. The test case in #36515 feels very artificial, so I don't feel an heuristic targeted at it would improve performance in the real world. Therefore, I'm closing this PR until we can find something to base our heuristic on. |
Box<T>
drop glue is pretty simple and should not lead to blow-up problems.Moreover, not inlining it leads to LLVM pessimizing some pointer-based
optimizations because it thinks the pointer passed to the drop glue could be
escaped.
Fixes #46515. However, this is not a great fix -- the problem still exists for
other smart pointers, e.g.
Rc
andArc
.Cc @arielb1 who wrote the "
noinline
drop glue" patch (#42771).