-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Delete GT_ASG
#85871
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
Delete GT_ASG
#85871
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsMeasuring TP.
|
676e5b7 to
017f98c
Compare
017f98c to
004b6bb
Compare
863a694 to
77f7cb6
Compare
77f7cb6 to
8810b14
Compare
Of course, there is also a very nice TP diff. |
|
/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress, runtime-coreclr outerloop, runtime-coreclr gcstress0x3-gcstress0xc |
|
Azure Pipelines successfully started running 4 pipeline(s). |
|
Stress results analysis:
|
AndyAyersMS
left a comment
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 looked through everything and only have a few minor comment suggestions.
One broader nit is that we now use "value" and "data" somewhat interchangeably for what we used to sometimes call the RHS. I personally find "value" to be more semantically inspiring but don't feel like making a change here—assuming we decide we should—should hold up this PR.
Given the volume of the diffs it would be good to get a second reviewer. I would also like to hold off merging this until after the preview 5 snap tomorrow.
@jakobbotsch can you also do a review?
|
|
||
| int aflags = isLoadAddress ? CORINFO_ACCESS_ADDRESS : CORINFO_ACCESS_GET; | ||
| GenTree* obj = nullptr; | ||
| GenTreeFlags indirFlags = impPrefixFlagsToIndirFlags(prefixFlags); |
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.
These aren't used until ~170 lines later, can we move this down closer to the use?
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.
In the store case (below) there are quite a few more uses, so if you want to leave things this way for symmetry then perhaps mark it as const so it is clearer nothing in between is modifying it?
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 flags may get modified by the call impImportStaticFieldAddress, this happens when importing a static readonly object field. I can move both of these declarations closer to their uses if you think it would be better (the motivation for having this them this high up was indeed symmetry).
Agree on that, there will be another "comment fixes" PR and I can fix |
| void MoveNodeToEnd(GenTreeLclVarCommon* node) | ||
| { | ||
| if (node->gtNext == nullptr) | ||
| if ((m_prevNode == node) || (node->gtNext == nullptr)) |
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.
Is node->gtNext == nullptr a meaningful check if SequenceLocal no longer unconditionally clears it?
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 had to recheck, but it turns out the answer is yes. The scenario is when we have half-consistent state during local morph with m_stmtModified == true and a new (bashed to) local address node inserted into the tree. Arguably, we should not be sequencing locals once m_stmtModified becomes true, but that is pre-existing behavior.
jakobbotsch
left a comment
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 also, great work!
|
Thanks again! Awesome to have this in! |
|
@SingleAccretion Thanks again for all your fantastic work improving the JIT! |
|
Is there an issue tracking #10873 (comment) (for the remainder of rationalizer phase)? |
|
I don't think there is; moving rationalization upwards means LIRizing HIR, which I don't believe there are plans for at this point in time. |


After many years of existing and some weeks of removal work,
GT_ASG, the last large IR quirk, becomes no more, giving way to the store nodes in the entirety of the compiler.Closes #10873.