-
Notifications
You must be signed in to change notification settings - Fork 5.5k
JIT: Optimize data flow used in assertion prop/CSE #94701
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 |
|---|---|---|
|
|
@@ -58,19 +58,48 @@ void DataFlow::ForwardAnalysis(TCallback& callback) | |
| } | ||
| else | ||
| { | ||
| FlowEdge* preds = m_pCompiler->BlockPredsWithEH(block); | ||
| for (FlowEdge* pred = preds; pred; pred = pred->getNextPredEdge()) | ||
| for (FlowEdge* pred : block->PredEdges()) | ||
| { | ||
| callback.Merge(block, pred->getSourceBlock(), pred->getDupCount()); | ||
| } | ||
| } | ||
|
|
||
| if (callback.EndMerge(block)) | ||
| { | ||
| block->VisitAllSuccs(m_pCompiler, [&worklist](BasicBlock* succ) { | ||
| // The clients using DataFlow (CSE, assertion prop) currently do | ||
| // not need EH successors here: | ||
| // | ||
| // 1. CSE does not CSE into handlers, so it considers no | ||
| // expressions available at the beginning of handlers; | ||
| // | ||
| // 2. Facts in global assertion prop are VN-based and can only | ||
| // become false because of control flow, so it is sufficient to | ||
| // propagate facts available into the 'try' head block, since that | ||
| // block dominates all other blocks in the 'try'. That will happen | ||
| // as part of processing handlers below. | ||
| // | ||
| block->VisitRegularSuccs(m_pCompiler, [&worklist](BasicBlock* succ) { | ||
| worklist.insert(worklist.end(), succ); | ||
| return BasicBlockVisit::Continue; | ||
| }); | ||
| } | ||
|
|
||
| if (m_pCompiler->bbIsTryBeg(block)) | ||
|
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 do we not need to consider the exceptional successors of filters here? (Not saying we should)
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. Do you mean the second pass EH successors?
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.
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 think that because the filter and its enclosed handlers are all dominated by a same try entry there is no need to consider the filter as a pred of those handlers. |
||
| { | ||
| // Handlers of the try are reachable (and may require special | ||
| // handling compared to the normal "at-the-end" propagation above). | ||
| EHblkDsc* eh = m_pCompiler->ehGetDsc(block->getTryIndex()); | ||
| do | ||
| { | ||
| worklist.insert(worklist.end(), eh->ExFlowBlock()); | ||
|
|
||
| if (eh->ebdEnclosingTryIndex == EHblkDsc::NO_ENCLOSING_INDEX) | ||
| { | ||
| break; | ||
| } | ||
|
|
||
| eh = m_pCompiler->ehGetDsc(eh->ebdEnclosingTryIndex); | ||
| } while (eh->ebdTryBeg == block); | ||
| } | ||
| } | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
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.
This was pretty meaningless -- intersecting with the lexically last block of a try region shouldn't be sufficient to guarantee any form of correctness here.