Haha another small apology -- Luke you may be wondering, why implement tail entries when we are not working on tail calls?
The answer is in the design doc:
> As an optimization, when control enters an indirect entry trampoline, the trampoline can check if the incoming WasmTlsReg is actually same-instance, and in that case can jump to the type-checking direct entry. In that case there will be no trampoline frame and the callee will return directly to the caller.
So in that case, the trampoline can tail-call the callee, by jumping to the callee's tail entry. But because the trampoline can't currently check the callee's signature, we target the *checked* tail entry.
AFAIU the *unchecked* tail entry would only ever be invoked by a direct tail call from the tail calls proposal, so I guess that bit isn't strictly necessary.
Bug 1639153 Comment 8 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Haha another small apology -- Luke you may be wondering, why implement tail entries when we are not working on tail calls?
The answer is in the design doc:
> As an optimization, when control enters an indirect entry trampoline, the trampoline can check if the incoming WasmTlsReg is actually same-instance, and in that case can jump to the type-checking tail entry. In that case there will be no trampoline frame and the callee will return directly to the caller.
So in that case, the trampoline can tail-call the callee, by jumping to the callee's tail entry. But because the trampoline can't currently check the callee's signature, we target the *checked* tail entry.
AFAIU the *unchecked* tail entry would only ever be invoked by a direct tail call from the tail calls proposal, so I guess that bit isn't strictly necessary.