Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 8 additions & 5 deletions src/coreclr/jit/assertionprop.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -5488,8 +5488,14 @@ 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 since
// assertions are VN-based and can never become false.
//
void MergeHandler(BasicBlock* block, BasicBlock* firstTryBlock, BasicBlock* lastTryBlock)
{
if (VerboseDataflow())
Expand All @@ -5498,11 +5504,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);

@jakobbotsch jakobbotsch Nov 14, 2023

Copy link
Copy Markdown
Member Author

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.

}

// At the end of the merge store results of the dataflow equations, in a postmerge state.
Expand Down
35 changes: 32 additions & 3 deletions src/coreclr/jit/dataflow.h
Original file line number Diff line number Diff line change
Expand Up @@ -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))

@SingleAccretion SingleAccretion Nov 14, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The 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)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean the second pass EH successors?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The 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);
}
}
}