Update GetElement and ToScalar to lower IND, LCL_FLD, and LCL_VAR specially #86400
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsThis resolves #86345 by updating the lowering of In particular we see many diffs such as: cmp edx, 4
jae SHORT G_M33861_IG04
- vmovups xmm0, xmmword ptr [rcx]
- vmovaps xmmword ptr [rsp+20H], xmm0
- vmovss xmm0, dword ptr [rsp+4*rdx+20H]
+ vmovss xmm0, dword ptr [rcx+4*rdx]
|
|
CC. @dotnet/jit-contrib |
| BlockRange().Remove(op2); | ||
|
|
||
| int32_t addOffset = (static_cast<uint8_t>(op2->AsIntCon()->IconValue()) % count); | ||
| addOffset *= static_cast<int32_t>(elemSize); |
There was a problem hiding this comment.
is it possible to go out of bounds here?
There was a problem hiding this comment.
The constant is restricted to between 0..255 and then % count That means its already never going to be more than 64. Vector512<byte> is 63, Vector512<long> is 7 * 8 == 56, etc
Combined with the range check we've already emitted for non-constant indices where required means we should always end up with something that is in range.
Except maybe there's still some edge case for the existing offset being int.MaxValue though? Maybe *(basePtr + int.MaxValue).GetElement(5)....
There was a problem hiding this comment.
Updated the check to cover if (op2->OperIsConst() && (newOffset < (INT32_MAX - comp->maxSIMDStructBytes()))) to handle such an extreme edge-case
There was a problem hiding this comment.
and logged #86609 to track an implicit truncation that GenTreeAddrMode is doing
This resolves #86345 by updating the lowering of
GetElement/ToScalarto specially handleGT_IND,GT_LCL_FLD, andGT_LCL_VAR.In particular we see many diffs such as:
cmp edx, 4 jae SHORT G_M33861_IG04 - vmovups xmm0, xmmword ptr [rcx] - vmovaps xmmword ptr [rsp+20H], xmm0 - vmovss xmm0, dword ptr [rsp+4*rdx+20H] + vmovss xmm0, dword ptr [rcx+4*rdx]