-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: fix incorrect scale in genCreateAddrMode + no-opt #75433
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsFixes #75312 The problem is basically in a tree:
that is an address for IND, for which, base = arg0 while offset should be 1
|
/azp run runtime-coreclr outerloop, runtime-coreclr jitstress, runtime-coreclr jitstressregs, runtime-coreclr gcstress0x3-gcstress0xc, Fuzzlyn |
Azure Pipelines successfully started running 5 pipeline(s). |
@kunalspathak Please prioritize to review this PR before RC2 snap. |
Have you analyzed any of these failures and are there anything related? |
cc @jeffschwMSFT. Once we complete this PR, we will backport this to 7.0 and 6.0. |
Jit stress failures look like known issues:
|
So the bug was an uninitialized local? How could we have not caught this before now? |
That's exactly I was wondering. Why it needed complex C++ / CLI only to reproduce? |
Ah, no, that change is unrelated, let me remove the redundant initialization actually, |
It's not C++ specific, it's just that This bug is a good example on why we need unit tests for jit phases |
Make sense. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
src/coreclr/jit/codegencommon.cpp
Outdated
{ | ||
/* Get hold of the index value */ | ||
ssize_t ixv = index->AsIntConCommon()->IconValue(); | ||
|
||
/* Scale the index if necessary */ | ||
ixv *= tmpMul; | ||
if (tmpMul) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So its ok to have tmpMul == 0
here from the else
on line 1417 and not scale?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it can be but only if we also disable jit optimizations and write IL for array[1 + 2]
because Roslyn will fold cns + cns too again (even in Debug mode).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, let me run a few more tests, probably some parts of this logic can be just removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunalspathak so I've slightly changed the logic - the whole block can be removed in theory but it produced several Tier0 regressions so I decided to keep it + special handled zero index or zero scale, so if optGetArrayRefScaleAndIndex
returns either 0 or non-zero but index
represents 0
then we drop the whole index part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens for !(rv2->OperIs(GT_MUL, GT_LSH) && (rv2->gtGetOp2()->IsCnsIntOrI()))
where we set index = rv2
?
else
{
/* May be a simple array. rv2 will points to the actual index */
index = rv2;
tmpMul = mul;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunalspathak good point, it explains a single regression in the jit-diffs, but overall the code as is correct, it's just that the block you highlighted handles constant index that is converted to constant offset (this path is never hit in optimized code from what I see)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me push a quick change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kunalspathak should be correct now and zero diff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Just double check if there are zero diffs for all archs before merging.
Yeah, the diff is empty but there is a conflict |
/backport to release/7.0 |
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3048213131 |
@kunalspathak could you also approve the backport - #75560 |
Fixes #75312
The problem is basically an incorrect behavior of genCreateAddrMode for the following tree:
for which,
genCreateAddrMode
returns:base = arg0
idx = nullptr
scale = 0
offset = 4
while offset should be 1