-
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
Delete GT_ASG
#85871
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:
|
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?
@@ -8813,8 +8829,9 @@ void Compiler::impImportBlockCode(BasicBlock* block) | |||
|
|||
JITDUMP(" %08X", resolvedToken.token); | |||
|
|||
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 |
{ | ||
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.
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.