Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
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
14 changes: 9 additions & 5 deletions src/coreclr/jit/assertionprop.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

@SingleAccretion SingleAccretion Nov 14, 2023

Choose a reason for hiding this comment

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

Note that if we did kill assertions...

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.

Copy link
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 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.

Copy link
Contributor

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?

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".

Copy link
Member Author

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.

Copy link
Member Author

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?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, thank you!

// try region.
void MergeHandler(BasicBlock* block, BasicBlock* firstTryBlock, BasicBlock* lastTryBlock)
{
if (VerboseDataflow())
Expand All @@ -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);
Copy link
Member Author

@jakobbotsch jakobbotsch Nov 14, 2023

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
34 changes: 31 additions & 3 deletions src/coreclr/jit/dataflow.h
Original file line number Diff line number Diff line change
Expand Up @@ -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())
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: can this loop use the PredEdges iterator?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, let me simplify this tomorrow.

{
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))
Copy link
Contributor

@SingleAccretion SingleAccretion Nov 14, 2023

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
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
Contributor

Choose a reason for hiding this comment

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

Yes.

Copy link
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);
}
}
}