JIT: Ignore source indir when checking interference for block store source address #78763
Conversation
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
…ource address
For block stores we can contain both the source and destination address.
Since the source is a value we will have an indirection on top of the
address, such as
N017 ( 6, 14) [000001] #---G------ t1 = ▌ IND ref REG x1 $240
┌──▌ t1 ref
N019 ( 8, 17) [000003] -c--G------ t3 = ▌ LEA(b+8) byref REG NA
┌──▌ t3 byref
N021 ( 32, 39) [000004] nc-XG--N--- t4 = ▌ IND struct REG NA
N023 (???,???) [000025] Dc--------- t25 = LCL_FLD_ADDR byref V03 tmp1 [+0] NA REG NA
┌──▌ t25 byref
├──▌ t4 struct
N025 ( 42, 46) [000017] sA--------- ▌ STORE_BLK struct<Xunit.StackFrameInfo, 16> (copy) (Unroll) REG NA
where [000004] is the source indirection and [000003] is the source
address. The existing containment check was checking interference of
[000003] with [000004], which is conservative given that the indirection
itself is always contained.
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsFor block stores we can contain both the source and destination address. Since the source is a value we will have an indirection on top of the address, such as where [000004] is the source indirection and [000003] is the source address. The existing containment check was checking interference of [000003] with [000004], which is conservative given that the indirection itself is always contained. This should fix some of the regressions seen in #78698.
|
Member
Author
|
cc @dotnet/jit-contrib PTAL @SingleAccretion @EgorBo |
SingleAccretion
approved these changes
Nov 23, 2022
EgorBo
approved these changes
Nov 23, 2022
Co-authored-by: SingleAccretion <[email protected]>
jakobbotsch
deleted the
block-store-contain-source-address-interference
branch
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
For block stores we can contain both the source and destination address. Since the source is a value we will have an indirection on top of the address, such as
where [000004] is the source indirection and [000003] is the source address. The existing containment check was checking interference of [000003] with [000004], which is conservative given that the indirection itself is always contained.
This should fix some of the regressions seen in #78698.