JIT: Fix new helper calls for some block copies involving promoted locals #86246
Conversation
…cals The change in dotnet#85620 was missing a check for the case where the destination is not on stack but the source is. The backend still uses a helper call for this case. The field-by-field case would also usually involve helper calls since it would normally need write barriers; however, the exception were for byref fields, so Span<T>/ReadOnlySpan<T> were particularly affected.
…moted locals" This reverts commit 1b84464.
This reverts commit 2ed28c2.
…ving promoted locals"" This reverts commit 9861135.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThe change in #85620 was missing a check for the case where the The field-by-field case would also usually involve helper calls since it
|
|
Ideally the backend should be fixed to be smarter about these block copies. The first problem is that we call a write barrier helper for Diffs of this change win-x64 diffs of this change against parent of #85620 Diffs above do not include benchmarks collections as the superpmi-collect is broken for them currently. |
|
cc @dotnet/jit-contrib PTAL @EgorBo |
|
@jakobbotsch I see a few size regressions where we emit now CORINFO_HELP_CHECKED_ASSIGN_REF instead of CORINFO_HELP_ASSIGN_BYREF, is that expected? |
Yes it's expected, those diffs are essentially just the reverse of #85620... using the checked write barrier helper that also increments dst/src instead of the "normal" checked write barrier. |
The change in #85620 was missing a check for the case where the
destination is not on stack but the source is. The backend still uses a
helper call for this case.
The field-by-field case would also usually involve helper calls since it
would normally need write barriers; however, the exception were for
byref fields, so Span/ReadOnlySpan were particularly affected.
This hopefully fixes #85987 and dotnet/perf-autofiling-issues#17605; I'll keep them open and recheck their perf graphs in a week or so to verify.