Widen return values in CallTailCallTarget stubs #55740
Conversation
In the managed calling convention the callee is responsible for widening the return value up to 4 bytes. We need to mimic this in portable tailcall helpers as the JIT cannot know which call eventually produced the value that was stored in the return value buffer passed to the dispatcher. Fix dotnet#55253
ghost
added
the
area-CodeGen-coreclr
|
/azp run runtime-coreclr tailcallstress |
|
No pipelines are associated with this pull request. |
|
/azp run runtime-coreclr jitstress |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
CI is running at https://dev.azure.com/dnceng/public/_build/results?buildId=1239894&view=results (normal) and https://dev.azure.com/dnceng/public/_build/results?buildId=1239922&view=results (jitstress). |
|
/azp run runtime-coreclr jitstress |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| if (isSigned) | ||
| pCode->EmitCONV_I4(); | ||
| else | ||
| pCode->EmitCONV_U4(); |
There was a problem hiding this comment.
Is this even needed?
There was a problem hiding this comment.
It should not be. EmitLDLOC should do the appropriate widening implicitly.
|
Why does the slow tail call path need to know about this? If the JIT wants to play calling convention tricks for fast tail calls, it is fine with me. But I think it would be preferable to keep the slow tail call path simple. |
|
The alternative is to reject explicit tail calls when there is implicit widening. That's what the logic has been previously. I took a look and ECMA-335 does seem to imply that tail. is permissible whenever the callee's return type is assignable-to the caller's return type, which covers these newly allowed scenarios if I'm not wrong. I don't have a strong opinion. It should not be difficult to reject explicit tailcalls when types are mismatching on the JIT side. Do you think that's better? |
|
Yes, I think it would be better to reject explicit tailcalls when the return types do not match exactly, like it was done before. The platform-specific (or CoreCLR/RyuJIT specific) calling convention details should not be leaking into when tailcalls work or do not work. |
|
Superseded by #55989. |
ghost
locked as resolved and limited conversation to collaborators
In the managed calling convention the callee is responsible for widening
the return value up to 4 bytes. We need to mimic this in portable
tailcall helpers as the JIT cannot know which call eventually produced
the value that was stored in the return value buffer passed to the
dispatcher.
Fix #55253