@oli @Wesley Wiser So I was thinking of following up #66282 with a targeted inliner. My idea is that we visit all the BBs and on a function call, we look for #[rustc_targeted_inline]
on the def_id
and then we do the inlining by adding some basic blocks to the end (I'll need to look for other subtleties). This is done in a one-shot fashion; we don't compute SCC or try to recursively inline. Thoughts?
I'm not opposed and it would be great to see some work done in this direction. I do think it would be nice if we only had 1 inliner though.
And I feel like there's something relatively simple that's wrong with the current one
@Wesley Wiser I agree with the end goal, but I was thinking that this would be a temporary thing while we figure out the general case
mainly to improve ?
The only real difference between what it currently does and what you've outlined above is that it doesn't only target #[rustc_targeted_inline]
I think all of the rest of the code is going to be pretty much the same
modulo bugs
To be clear, I'm not saying "don't do it". I just think that in the time it will take to write the new one, you could probably find and fix the issues with the current one :)
@Wesley Wiser oh; I'm a bit surprised... I assumed the current inliner uses SCC to inline recursively etc.
Yea I'd rather not build a second inliner that we'll have to maintain
let's "just" fix the existing one
is there somewhere I can read about the issues with the current inliner?
other than the panics happening when you run it on stage 2, I don't think so
@Wesley Wiser oh; I'm a bit surprised... I assumed the current inliner uses SCC to inline recursively etc.
Nope, it should and niko wants it to but currently it just calls tcx.optimized_mir(callee_def_id)
and handles the cycle error by bailing out.
Sounds like I'd need to go on a fishing expedition then :P