Do we want to avoid allocation for wrapped function with different signatures #5862
Description
Related to #5504, but different.
For same signatures of the inner and the outer wrapper we can often both unwrap calls avoid extra invoke) and avoid extra allocation to fit the wrapped function. But sometimes just call unwrapping is possible.
For different signatures of the inner and the outer wrapper we are not allowed to unwrap calls. The WP only permits unwrapping for the matching signatures, and apparently there's no way to do this for the mismatched signatures anyway. But we can still avoid extra allocation if possible.
The allocation avoidance would be somewhat complicated and related to ABI.
So, I'm asking first, whether we want this.
There are two distinct cases, for which this question needs to be answered separately.
move_only_function or copyable_function
Or a mix of them.
Since we cannot unwrap calls, there would be pointer to outer thunk and pointer to inner thunk, that both needs to be stored, plus the usual function payload. We cannot fit it all to the outer wrapper, unless the inner wrapper does not use all it buffer, and we know it.
This can be achieved by saving size somewhere. Then when having wrapping, we can check if we have some space, and if so, avoid allocation.
I think the saving size as emulated vtable member would work.
This is certainly breaking move_only_function ABI, so it is "now or never" for some extended but not very much understanding of "now".
function wrapped into move_only_function
The #5808 can be (relatively) easily extended to handle mismatching signatures.
This does not have "where to put thunk" problem, because whereas function and move_only_function have the same signatures, the function vtable (a real C++ vtable, not an emulated one) resides with callable, and in small mode it occupies one of storage pointers. So we don't need to fit extra thunk pointer anywhere, it is already there bundled with callable.
The caveat is that if vNext ever happens, and if we indeed want to switch function to move_only_function machinery implementation, and gain all the new machinery advantages, then this approach can no longer work. Instead, the approach discussed above can work, but if we decide against it in vNext, we will have perf regression in this area, we will regress this whole optimization.