JIT: Induce more physical promotions #87810
Conversation
ghost
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThere are frequently cases where we have made no physical promotions, but still have assignments between regularly promoted structs and physically promoted structs (e.g. STORE_LCL_FLD(V00, LCL_VAR(V01)) where V00 is a candidate and V01 is regularly promoted). For these cases it's often beneficial to induce physical promotion.
|
jakobbotsch
force-pushed
the
physical-promotion-induce-always
branch
from
6d27b8b to
b03021e
Compare
jakobbotsch
changed the title
Two improvements: 1. Even if we haven't made any physical promotions it is still beneficial to go through and try to induce promotions from assignments between regular promotions and physical promotion candidates (e.g. STORE_LCL_FLD(V00, LCL_VAR(V01)) where V00 is a candidate and V01 is regularly promoted). 2. The logic to save candidate stores was missing the case where the regularly promoted struct is the destination and the source is the physical promotion candidate. Fix this by handling stores separately from candidates. This shows up as a TP regression, but the regression mainly comes from the work around the new promotions (new IR, more work as part of replacement), not from actually picking the promotions themselves.
jakobbotsch
force-pushed
the
physical-promotion-induce-always
branch
from
b03021e to
46d171b
Compare
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-jit-experimental |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-jit-experimental |
|
Azure Pipelines successfully started running 3 pipeline(s). |
Diff results are being truncated because there is a field called <Option>k__BackingField and <option> is an HTML tag.
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-jit-experimental |
|
Azure Pipelines successfully started running 3 pipeline(s). |
| inside_diff = False | ||
| new_lines.append(html_color_diff(cur_diff_lines)) | ||
| elif inside_diff: | ||
| cur_diff_lines.append(line) |
There was a problem hiding this comment.
This change was merged separately in #87861, so it won't be part of the commit after I squash-merge.
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS Failures are known according to build analysis. Diffs with physical promotion enable. Should be no diffs with old promotion disabled (since then there are no regularly promoted structs to induce accesses from). As mentioned above the TP cost is mainly due to the work around having more promotions to do, not due to the actual picking code. The TP cost in ARM32 is oddly significantly higher than elsewhere, I collected detailed stats and the top method is |
ghost
locked as resolved and limited conversation to collaborators
2 participants
Two improvements:
beneficial to go through and try to induce promotions from
assignments between regular promotions and physical promotion
candidates (e.g. STORE_LCL_FLD(V00, LCL_VAR(V01)) where V00 is a
candidate and V01 is regularly promoted).
regularly promoted struct is the destination and the source is the
physical promotion candidate. Fix this by handling stores separately
from candidates.
This shows up as a TP regression, but the regression mainly comes from
the work around the new promotions (new IR, more work as part of
replacement), not from actually picking the promotions themselves.
Detailed TP breakdown of `realworld`