@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