-
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 optimization removes some necessary code in .NET Core 3.0/3.1 #764
Comments
/cc @dotnet/jit-contrib |
The importer reorders T tmp = _value;
_value = null; when inlining
This reordering doesn't happen unless Looking at what 2.x did now to see why we regressed here. |
Haven't pinned down exactly where this regressed, though I believe the following changes are related:
Here's what happens in the importer after creating IR for the
One possible avenue to explore for a fix: because the Another oddity here is that the |
Using |
@AndyAyersMS - that makes sense. I assume you mean |
Not need at the moment as the importer doesn't generate |
I've been looking into that a while ago. In fact I already did it but it results in a small regression due to GC/non-GC type mismatch in LSRA that prevents 0 constant reg reuse and I'm trying to fix that first. |
Yes, something like this: else if (lhs->OperIsBlk())
{
// Check for ADDR(LCL_VAR), or ADD(ADDR(LCL_VAR),CNS_INT))
// (the latter may appear explicitly in the IL).
// Local field stores will cause the stack to be spilled when
// they are encountered.
GenTree* lclTree = nullptr;
if (impIsAddressInLocal(lhs->AsBlk()->Addr(), &lclTree))
{
lclVar = lclTree->AsLclVarCommon();
}
}
It is certainly convoluted.... It would appear that the SPILL_APPEND check is only supposed to handle special cases that later analysis in |
If we're appending an assignment whose LHS is is a location within a local struct, we need to spill all references to that struct from the eval stack. Update the existing logic for this to handle the case where the LHS is a field of a local struct, and the field is updated by unusual means (here, `initobj`). Fixes dotnet#764.
If we're appending an assignment whose LHS is is a location within a local struct, we need to spill all references to that struct from the eval stack. Update the existing logic for this to handle the case where the LHS is a field of a local struct, and the field is updated by unusual means (here, `initobj`). Fixes #764.
Release/3.1 port of dotnet/runtime#797. Fixes dotnet/runtime#764 The jit might incorrectly order a read from a struct field with an operation that modifies the field, so that the read returns the wrong value. Silent bad code; program behaves incorrectly. Yes, introduced in the 3.0 cycle. Verified the user's test case now passes; no diffs seen in any existing framework or test code. **Low**: the jit is now spilling the eval stack entries to temps in cases where it did not before; this should be conservatively safe. cc: @Brucefo ____ If we're appending an assignment whose LHS is is a location within a local struct, we need to spill all references to that struct from the eval stack. Update the existing logic for this to handle the case where the LHS is a field of a local struct, and the field is updated by unusual means (here, `initobj`). Fixes dotnet/runtime#764.
* [release/3.1] Port fix for JIT silent bad code Release/3.1 port of dotnet/runtime#797. Fixes dotnet/runtime#764 The jit might incorrectly order a read from a struct field with an operation that modifies the field, so that the read returns the wrong value. Silent bad code; program behaves incorrectly. Yes, introduced in the 3.0 cycle. Verified the user's test case now passes; no diffs seen in any existing framework or test code. **Low**: the jit is now spilling the eval stack entries to temps in cases where it did not before; this should be conservatively safe. cc: @Brucefo ____ If we're appending an assignment whose LHS is is a location within a local struct, we need to spill all references to that struct from the eval stack. Update the existing logic for this to handle the case where the LHS is a field of a local struct, and the field is updated by unusual means (here, `initobj`). Fixes dotnet/runtime#764. * Fix test
If the next code will be built in the Release configuration, an exception will be thrown because the object summary is null. This affects only .NET Core 3.0 and later. There is no issue in .NET Core 1.0-2.2.
There are some ways to fix an issue under .NET Core 3.0:
Ptr.Release()
method.private T _value;
member of Ptr class of typeobject
).Disassembly of JITed code in .NET Core 3.1:
Disassembly of JITed code in .NET Core 2.2:
The test project was attached:
JitOptimizationFailure.zip
category:correctness
theme:importer
skill-level:intermediate
cost:small
The text was updated successfully, but these errors were encountered: