JIT: Prefer block copies for unenregisterable locals even with GC pointers #85620
Conversation
…nters This comment seems outdated/wrong, the backend's block copy strategy when GC pointers are involved is highly tuned and often no helper is necessary at all.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThis comment seems outdated/wrong, the backend's block copy strategy when GC pointers are involved is highly tuned and often no helper is necessary at all.
|
Indeed (when we know the struct is going to be on stack anyway). |
|
Although, I guess we'll still be doing GPR movs (can't use SIMD for structs with gc handles) so I thought it's basically the same as physical promotion? |
The backend does use SIMD copies even when GC pointers are involved by disabling GC during the copy. |
…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.
…cals (#86246) 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<T>/ReadOnlySpan<T> were particularly affected.
ghost
locked as resolved and limited conversation to collaborators
This comment seems outdated/wrong, the backend's block copy strategy when GC pointers are involved is highly tuned and often no helper is necessary at all.