-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Improve static field access for NativeAOT #63620
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8231,6 +8231,35 @@ GenTree* Compiler::impImportStaticFieldAccess(CORINFO_RESOLVED_TOKEN* pResolvedT | |
| } | ||
| break; | ||
|
|
||
| case CORINFO_FIELD_STATIC_DATASEGMENT: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This does look a lot like I realize it won't work as-is because the Jit assumes Edit: on second thought, plumbing this through
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The difference from It was the feedback from dotnet/corert#5131 (comment) (my earlier attempt) that ended up going the |
||
| { | ||
| #ifdef FEATURE_READYTORUN | ||
| assert(opts.IsReadyToRun()); | ||
| assert((pFieldInfo->fieldFlags & CORINFO_FLG_FIELD_INITCLASS) == 0); | ||
|
|
||
| if (pFieldInfo->fieldLookup.accessType == InfoAccessType::IAT_VALUE) | ||
| { | ||
| op1 = gtNewIconHandleNode((size_t)pFieldInfo->fieldLookup.addr, GTF_ICON_STATIC_HDL); | ||
| op1->gtType = TYP_BYREF; | ||
| } | ||
| else | ||
| { | ||
| assert(pFieldInfo->fieldLookup.accessType == InfoAccessType::IAT_PVALUE); | ||
| op1 = gtNewIndOfIconHandleNode(TYP_BYREF, (size_t)pFieldInfo->fieldLookup.addr, GTF_ICON_GLOBAL_PTR, false); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
What is the scenario where the address of the static can change? Note that some code in the Jit depends on the addresses of statics being invariant. It will not matter for this change now, I believe, but I have changes in progress that will make this dependency more visible. (To be clear: mutable addresses can absolutely be made to work, I just need to understand the scenarios I will need to add as tests to account for them)
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. gtNewIndOfIconHandleNode asserts if GTF_ICON_GLOBAL_PTR is used with isInvariant = true. This was just me hammering on it until it worked. Maybe we need a new
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, a new handle kind would be the best solution ( Why a new handle kind?A "raw" // We will have staticPtr = IND(STATIC_ADDR_PTR) and give "staticPtr" a "VNF_PtrToStatic" VN.
ref var staticPtr = ref staticField;
staticPtr = { ... }; // The compiler will be able to see that this store is just "staticField = { ... }"It will be very similar to |
||
| } | ||
|
|
||
| FieldSeqNode* fs = GetFieldSeqStore()->CreateSingleton(pResolvedToken->hField); | ||
| op1 = gtNewOperNode(GT_ADD, TYP_BYREF, op1, | ||
| new (this, GT_CNS_INT) GenTreeIntCon(TYP_INT, pFieldInfo->offset, fs)); | ||
MichalStrehovsky marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| // Prevent CSE from adding the offset to the base | ||
| op1->gtFlags |= GTF_DONT_CSE; | ||
|
Comment on lines
+8255
to
+8256
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why prevent CSE unconditionally? At least for the Is the issue here that we cannot fold
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I was seeing RyuJIT fold the constant handle with the constant and that created an invalid handle (the handle is not an address when we're AOT compiling. It's an actual handle that should not be done constant propagation math on). Could be that this is a bug in CSE.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see. I think I know what the issue is (it should be a VN + assertion propagation bug). Could you open a bug on this and add a |
||
| #else | ||
| unreached(); | ||
| #endif // FEATURE_READYTORUN | ||
| } | ||
| break; | ||
|
|
||
| default: | ||
| { | ||
| // Do we need the address of a static field? | ||
|
|
@@ -15567,6 +15596,7 @@ void Compiler::impImportBlockCode(BasicBlock* block) | |
| case CORINFO_FIELD_STATIC_SHARED_STATIC_HELPER: | ||
| case CORINFO_FIELD_STATIC_GENERICS_STATIC_HELPER: | ||
| case CORINFO_FIELD_STATIC_READYTORUN_HELPER: | ||
| case CORINFO_FIELD_STATIC_DATASEGMENT: | ||
| op1 = impImportStaticFieldAccess(&resolvedToken, (CORINFO_ACCESS_FLAGS)aflags, &fieldInfo, | ||
| lclTyp); | ||
| break; | ||
|
|
@@ -15838,6 +15868,7 @@ void Compiler::impImportBlockCode(BasicBlock* block) | |
| case CORINFO_FIELD_STATIC_SHARED_STATIC_HELPER: | ||
| case CORINFO_FIELD_STATIC_GENERICS_STATIC_HELPER: | ||
| case CORINFO_FIELD_STATIC_READYTORUN_HELPER: | ||
| case CORINFO_FIELD_STATIC_DATASEGMENT: | ||
| op1 = impImportStaticFieldAccess(&resolvedToken, (CORINFO_ACCESS_FLAGS)aflags, &fieldInfo, | ||
| lclTyp); | ||
| break; | ||
|
|
||
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 have documentation above on what the various accessors mean, it would be nice to update it to cover this new value.
(I realize some of it is rather outdated)