[clr-interp] Fix peepCallConfigureAwait* peeps#129978
Open
BrzVlad wants to merge 2 commits into
Open
Conversation
The parsing validation was not matching the actual opcode peeps. Added comments and reordered the parsing in opcode order to make it easier to follow. All these peeps failed on ConfigureAwait patterns, as tested on local sample. Validated both from C# as well as IL, to also hit the large local index path. Fixes System.Threading.Tasks.Tests.AsyncProfilerTests.RuntimeAsync_ConfigureAwaitFalse
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the CoreCLR interpreter’s async-call peephole checks to align validation/parsing with the actual opcode peep patterns for ConfigureAwait(...) sequences, improving correctness and making the logic easier to follow.
Changes:
- Fix
ConfigureAwaitTask peephole parsing to use the correct pattern offsets for theldc.i4.*context flag and method tokens. - Reorder and correct ValueTask
ConfigureAwaitpeephole parsing/validation (including local index match andldc.i4.*handling) to reflect opcode order. - Add concise IL pattern comments above the affected checks to document the intended sequences.
jakobbotsch
approved these changes
Jun 29, 2026
Member
Author
|
/azp run runtime-libraries-interpreter |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Peeps don't contain all matching opcodes. For example:
```
static OpcodePeepElement peepRuntimeAsyncCallConfigureAwaitValueTask_L_L[] = {
// Call or CallVirt at the start (at offset 0)
{ 5, CEE_STLOC},
{ 9, CEE_LDLOCA },
// LDC_I4_0 or LDC_I4_1 goes here (at offset 13
{ 14, CEE_CALL},
{ 19, CEE_CALL },
{ 24, CEE_ILLEGAL } // End marker
```
m_pCBB is the current basic block. Aka the bblock that the call at offset 0 belongs to. All future opcodes in the peep have not yet been reached by the interpreter compiler so the offset to bb isn't initialized for them (only the first instruction in the bblock is mapped). This means that, in the above example, we could have code where LDC_I4 is the first instruction in the bblock and previous code was failing to check it. The fix avoids storing extra information in the peeps for this minor check, instead validating each il offset in the peep range.
Member
Author
|
/azp run runtime-libraries-interpreter |
Member
Author
|
/azp run runtime-interpreter |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The parsing validation was not matching the actual opcode peeps. Added comments and reordered the parsing in opcode order to make it easier to follow.
All these peeps failed on ConfigureAwait patterns, as tested on local sample. Validated both from C# as well as IL, to also hit the large local index path.
Fixes newly added System.Threading.Tasks.Tests.AsyncProfilerTests.RuntimeAsync_ConfigureAwaitFalse