What we usually do with these calls, i.e. in the CodeStubAssembler based builtins, is just connect them directly to End via a Return; they don't return a value, but that doesn't matter. Code size overhead is tiny, usually one jmp. Is there a particular use case where the jmp overhead would be noticable?

We do have lots of these in WASM, though fewer now with TrapIf. It would be good to get rid of the frame deconstruction and jump overhead. AFAICT this also introduces some overhead in the register allocator, since it must introduce ranges to split ranges over this call, though nothing should be alive across this call.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot