Uh oh!
There was an error while loading. Please reload this page.
JIT: Ignore source indir when checking interference for block store source address - #78763
Conversation
…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
commented
Nov 23, 2022
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.
|
jakobbotsch
commented
Nov 23, 2022
cc @dotnet/jit-contrib PTAL @SingleAccretion@EgorBo |
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
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.