-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix CoreRT frozen strings handling. #45095
Conversation
@@ -1625,7 +1625,11 @@ void Compiler::optDebugCheckAssertion(AssertionDsc* assertion) | |||
assert(assertion->op2.u1.iconFlags != 0); | |||
break; | |||
case O1K_LCLVAR: | |||
assert((lvaTable[assertion->op1.lcl.lclNum].lvType != TYP_REF) || (assertion->op2.u1.iconVal == 0)); | |||
if (!IsTargetAbi(CORINFO_CORERT_ABI)) // CoreRT allows non-zero const refs for frozen strings. |
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.
The frozen strings are not really inherent part of CoreRT ABI. Nothing prevents them from being used with CoreCLR as well, we just happen to not do that currently.
It would be better to have a bool frozenObjectsUsed;
flag that gets set whenever the JIT/EE interface returns a frozen object, and use this flag for these asserts.
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.
good idea, thank you, fixed.
@MichalStrehovsky Is this known? |
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. Thanks!
Nope but we're not running the tests very often and the runs have been very noisy ever since we picked up the regression this and the previous pull request is fixing. I'll take a look once this is mirrored over. Maybe we should make Pri0 runs mandatory in the CI. |
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.
Currently you have a broad permissive check. Should we instead do more surgical fine-grained checks by instead asserting that any nonzero TYP_REF integer must be a string handle?
I'm surprised we don't hit asserts elsewhere.
noway_assert(!"unreachable IAT_VALUE case in gtNewStringLiteralNode"); | ||
} | ||
|
||
setMethodHasFrozenString(); |
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.
We only see these on CoreRT, so should we keep part of the old assertion check?
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.
#45095 (comment) there was a discussion about it
assert(obj->IsIconHandle(GTF_ICON_STR_HDL)); | ||
if (!doesMethodHaveFrozenString()) | ||
{ | ||
assert(compIsForInlining()); |
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.
I have pushed additional changes for a case where we inline a method and pass such string there(as an argument), the inlinee doesn't have a frozen string flag so the check was failing.
Thank you! |
Fix asserts about const non-zero refs that are possible on CoreRT, in the past they were always hidden with
GT_NOP
but it was creating other issues.It should fix failures seen in dotnet/runtimelab#374 (comment) introduced by #44398.
With the changes the tests results are:
the 13 failing tests are failing without the change as well, so they are probably preexisting, PTAL @jkotas :
before the fix there were 90 failures including this 13.
PTAL @dotnet/jit-contrib