-
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: checked-release asmdiffs for libraries_tests.run.linux.arm64.Release.mch #105971
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
@amanasifkhalid, PTAL. |
I'm seeing behavioral diffs in the ldr w1, [x19, #0x28]
and w1, w1, #0x7FFFFFFF
ldp w0, w2, [x19, #0x2C]
mul w25, w1, w0
add w1, w25, w2
add w1, w1, #21
ldr w0, [x19, #0x4C]
ldr w2, [x19, #0x34]
sub w0, w0, w2
cmp w0, w1 but not for the Release JIT: ldr w1, [x19, #0x28]
and w1, w1, #0x7FFFFFFF
ldr w0, [x19, #0x2C]
mul w25, w1, w0
ldr w1, [x19, #0x30]
add w1, w25, w1
add w1, w1, #21
ldr w0, [x19, #0x4C]
ldr w2, [x19, #0x34]
sub w0, w0, w2
cmp w0, w1 Here's another instance where the register pairing is different. Checked JIT: ldr w0, [x19, #0x28]
and w0, w0, #0x7FFFFFFF
ldp w1, w2, [x19, #0x2C]
mul w0, w0, w1
sxtw w28, w0
add w0, w28, w2
add w1, w0, #21
ldr w0, [x19, #0x4C]
ldr w2, [x19, #0x34]
sub w0, w0, w2
cmp w0, w1 Release JIT: ldr w0, [x19, #0x28]
and w0, w0, #0x7FFFFFFF
ldr w1, [x19, #0x2C]
mul w0, w0, w1
sxtw w28, w0
ldp w0, w1, [x19, #0x30]
add w0, w28, w0
add w2, w0, #21
ldr w0, [x19, #0x4C]
sub w0, w0, w1
cmp w0, w2 |
I suspect we aren't maintaining our DFS/loop data structures consistently between Debug/Release builds, and #105695 exposed this inconsistency (for example, by the time we get to |
Fortunately, the problem is more localized than I initially thought: In if ((prevIndir->gtLIRFlags & LIR::Flags::Mark) != 0)
{
JITDUMP("Previous indir is part of the data flow of current indir\n");
UnmarkTree(indir);
return false;
} Right before that, there's some Debug code for dumping LIR: #ifdef DEBUG
bool isClosed;
GenTree* startDumpNode = BlockRange().GetTreeRange(prevIndir, &isClosed).FirstNode();
GenTree* endDumpNode = indir->gtNext;
// Dumping logic below
So in Debug/Checked builds, if a node has this flag set upon entry into |
There is an invariant for LIR that |
This is pretty error prone -- can you switch it to use |
Thanks for pointing that out!
Sure. |
4 diffs overall, perhaps all the same or in a similar method
See https://dev.azure.com/dnceng-public/public/_build/results?buildId=765225&view=results
The text was updated successfully, but these errors were encountered: