JIT: Handle possibility of late optimized out async calls #121502
Conversation
If we optimize an async call away after the suspension/resumption code has been created then the emit locations used for resumption info and diagnostic info will not be valid. Handle this rare case by just storing 0. The value should not matter as we will never suspend here. Ideally we would model things so that suspension/resumption blocks could too be removed in these cases, but that's not so simple (we do not have a mechanism to represent a data dependency of a basic block, only a control flow dependency).
github-actions
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
There was a problem hiding this comment.
Pull Request Overview
This PR addresses a rare edge case where async calls are optimized away late in the compilation process, after suspension/resumption code has already been created. The fix ensures that invalid emit locations are safely handled by checking validity before use.
Key Changes
- Added validity checks for
emitLocationobjects before dereferencing them - Use fallback values (nullptr/0) when emit locations are invalid due to late optimizations
- Conditional relocation recording to avoid processing invalid targets
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/coreclr/jit/emit.cpp | Added validity check before calling emitOffsetToPtr, uses nullptr as fallback, and conditionally records relocation only for valid targets |
| src/coreclr/jit/codegencommon.cpp | Added validity check before calling CodeOffset, uses 0 as fallback for diagnostic native offset |
|
I will run this in the Libraries + async PR. In most legs this was the only failure remaining. |
I did not see the assert in the PR with these changes added |
|
/ba-g Android timeout, and async only change whose testing was done out-of-band |
3 participants
If we optimize an async call away after the suspension/resumption code has been created then the emit locations used for resumption info and diagnostic info will not be valid. Handle this rare case by just storing 0. The value should not matter as we will never suspend here.
Suspension blocks can be removed in this case, but resumption blocks cannot as they are referenced by the resumption switch. Ideally we would model things so that resumption blocks could too be removed in these cases, but that's not so simple.
Fixes issue reported in #121298 (comment)