-
Couldn't load subscription status.
- Fork 5.2k
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 1 commit
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 |
|---|---|---|
|
|
@@ -5488,8 +5488,15 @@ class AssertionPropFlowCallback | |
| // lastTryBlock - the last block of the try for "block" handler;. | ||
| // | ||
| // Notes: | ||
| // We can jump to the handler from any instruction in the try region. | ||
| // It means we can propagate only assertions that are valid for the whole try region. | ||
| // We can jump to the handler from any instruction in the try region. It | ||
| // means we can propagate only assertions that are valid for the whole | ||
| // try region. | ||
| // | ||
| // It suffices to intersect with only the head 'try' block's assertions, | ||
| // since that block dominates all other blocks in the try and we never | ||
| // kill assertions in global AP. Note that if we did kill assertions we | ||
| // would need to be more careful about our mid-block handling when in a | ||
| // try region. | ||
| void MergeHandler(BasicBlock* block, BasicBlock* firstTryBlock, BasicBlock* lastTryBlock) | ||
| { | ||
| if (VerboseDataflow()) | ||
|
|
@@ -5498,11 +5505,8 @@ class AssertionPropFlowCallback | |
| Compiler::optDumpAssertionIndices("in -> ", block->bbAssertionIn, "; "); | ||
| JITDUMP("firstTryBlock " FMT_BB " ", firstTryBlock->bbNum); | ||
| Compiler::optDumpAssertionIndices("in -> ", firstTryBlock->bbAssertionIn, "; "); | ||
| JITDUMP("lastTryBlock " FMT_BB " ", lastTryBlock->bbNum); | ||
| Compiler::optDumpAssertionIndices("out -> ", lastTryBlock->bbAssertionOut, "\n"); | ||
| } | ||
| BitVecOps::IntersectionD(apTraits, block->bbAssertionIn, firstTryBlock->bbAssertionIn); | ||
| BitVecOps::IntersectionD(apTraits, block->bbAssertionIn, lastTryBlock->bbAssertionOut); | ||
|
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 was pretty meaningless -- intersecting with the lexically last block of a try region shouldn't be sufficient to guarantee any form of correctness here. |
||
| } | ||
|
|
||
| // At the end of the merge store results of the dataflow equations, in a postmerge state. | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -58,19 +58,47 @@ void DataFlow::ForwardAnalysis(TCallback& callback) | |
| } | ||
| else | ||
| { | ||
| FlowEdge* preds = m_pCompiler->BlockPredsWithEH(block); | ||
| for (FlowEdge* pred = preds; pred; pred = pred->getNextPredEdge()) | ||
| for (FlowEdge* pred = block->bbPreds; pred; pred = pred->getNextPredEdge()) | ||
|
||
| { | ||
| 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. Assertion prop never kills any assertions, so it is | ||
| // sufficient to propagate facts from the 'try' head block, since | ||
| // that block dominates all other blocks in the 'try'. That happens | ||
| // implicitly below. | ||
| // | ||
| block->VisitRegularSuccs(m_pCompiler, [&worklist](BasicBlock* succ) { | ||
| worklist.insert(worklist.end(), succ); | ||
| return BasicBlockVisit::Continue; | ||
| }); | ||
| } | ||
|
|
||
| if (m_pCompiler->bbIsTryBeg(block)) | ||
|
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) 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? 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. 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.
In my opinion, it is confusing to talk about the possibility of "killing assertions" in global AP. How would that work? It seems impossible almost by definition of the algorithm.
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 mean because we use SSA/VN? I mean if facts could become false in other ways than due to control flow joins. We would need to propagate that to the handlers.
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.
Right. VNs are "immutable", so if a a fact about a VN dominates a subgraph, it will always be true on the entirety of that subgraph. I understand the comment, I would just request to reword to not mention AP along the lines of "no clients need the concept of 'kill's".
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, I can reword it tomorrow.
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 think the wording looks better now?
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.
Yes, thank you!