-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Fold "cns"[cns] for ROS<char> #78593
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 3 commits
c0abbd7
92a9e38
e12b055
f030653
093fd77
022e744
369179d
548fad8
37dadee
fc6f592
b406c17
8f7f144
0c8a8cc
53cbfe8
f7d9b29
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 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -7884,7 +7884,7 @@ void Compiler::fgValueNumberBlock(BasicBlock* blk) | |||||||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||||||||
| // Set up ambient var referring to current tree. | ||||||||||||||||||||||||||||||||||
| compCurTree = tree; | ||||||||||||||||||||||||||||||||||
| fgValueNumberTree(tree); | ||||||||||||||||||||||||||||||||||
| fgValueNumberTree(tree, stmt); | ||||||||||||||||||||||||||||||||||
| compCurTree = nullptr; | ||||||||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
|
|
@@ -8492,7 +8492,98 @@ void Compiler::fgValueNumberSsaVarDef(GenTreeLclVarCommon* lcl) | |||||||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||||||||
| } | ||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||
| void Compiler::fgValueNumberTree(GenTree* tree) | ||||||||||||||||||||||||||||||||||
| //------------------------------------------------------------------------ | ||||||||||||||||||||||||||||||||||
| // fgValueNumberConstStringElemLoad: Try to match "cns_str"[cns_index] tree | ||||||||||||||||||||||||||||||||||
| // and apply a constant VN representing given char at cns_index in that string. | ||||||||||||||||||||||||||||||||||
| // | ||||||||||||||||||||||||||||||||||
| // Arguments: | ||||||||||||||||||||||||||||||||||
| // tree - the GT_IND node | ||||||||||||||||||||||||||||||||||
| // | ||||||||||||||||||||||||||||||||||
| // Return Value: | ||||||||||||||||||||||||||||||||||
| // true if the pattern was recognized and a new VN is assigned | ||||||||||||||||||||||||||||||||||
| // | ||||||||||||||||||||||||||||||||||
| bool Compiler::fgValueNumberConstStringElemLoad(GenTreeIndir* tree) | ||||||||||||||||||||||||||||||||||
| { | ||||||||||||||||||||||||||||||||||
| ValueNum addrVN = tree->gtGetOp1()->gtVNPair.GetLiberal(); | ||||||||||||||||||||||||||||||||||
| VNFuncApp funcApp; | ||||||||||||||||||||||||||||||||||
| if (!varTypeIsShort(tree) || !vnStore->GetVNFunc(addrVN, &funcApp)) | ||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||
| else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic)) | |
| { | |
| fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]); | |
| offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]); | |
| // Note VNF_PtrToStatic statics are currently always "simple". | |
| fgValueNumberFieldLoad(tree, /* baseAddr */ nullptr, fldSeq, offset); | |
| } | |
| else if (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir())) | |
| { | |
| // VN is assigned inside fgValueNumberConstLoad | |
| } | |
| else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem)) | |
| { | |
| fgValueNumberArrayElemLoad(tree, &funcApp); | |
| } |
Changed to TYP_SHORT (yes, it was a TP fast-out path)
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.
can you point me where exactly caller already did it? it seems like other paths also compute it
else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.
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.
do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up
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.
Sure.
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
EgorBo marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
Outdated
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.
It is not right to update side effects in VN like that. The problem this solves should be solved in some other way.
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.
@SingleAccretion Any recommendation and what's wrong with it? Unfortunately, I don't see a better option and this is required for this PR.
Alternative option I see is to define a new VN with "known-non-null" property and then fold it later e.g. at assertprop.
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.
Any recommendation
From the discussion yesterday - did making VN-based constant propagation run in post-order not work?
what's wrong with it
It's not in VN's contract to modify IR like this. Certainly, if you allow this, all sorts of things become possible (for example, here we would just bash the node to a CNS_INT directly).
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.
Thanks! Reverted the change, the suggestion about post-order works but I decided to postpone it to a separate PR so I can see if it worth the effort around TP and diffs (and planned a few experiments around that) so this PR does fold all the patterns I wanted it to, but might leave nullchecks in some cases.
Uh oh!
There was an error while loading. Please reload this page.