inlining: Don't inline concrete-eval'ed calls whose result was too large

[Keno]

This undoes some of the choices made in #47283 and #47305. As Shuhei correctly pointed out, even with the restriction to nothrow, adding the extra flags on the inlined statements results in incorrect IR. Also, my bigger motivating test case turns out to be insufficiently optimized without the effect_free flags (which I removed in the final revision of #47305). I think for the time being, the best course of action here is to just stop inlining concrete-eval'ed
calls entirely. The const result is available for inference, so in most cases the call will get deleted. If there's an important case we care about where this does not happen, we should take a look at that separately.

[vtjnash]

So this effectively reverts #47305? (just confirming understanding). This does seem to make more sense to me than the inlining we were doing.

[Keno]

It does, yes, but the testcase introduced by that PR still works, because now we just don't inline that call at all, so we can still delete it.

[Keno]

I'm gonna go ahead and merge this to fix #47374. We can continue discussing if there's better things to do here post-merge.

[vtjnash]

It seems like this might even be better, because the non-inlined version might instead have a constant-return calling convention (assuming it was derived from the types, and not the values themselves), and thus avoid doing the computation? And usually not worse (since out-lined code should not take much longer than in-lined)

[Keno]

Yeah, I think it's ok. One of the big reasons for inlining is to do getfield folding, etc., but since we know the constant value, we can already do that. We should be on the lookout for any cases where this causes an issue though.