Skip to content

Add a dominator-tree WTO utility for reducible CFGs - #9215

Open
tlively wants to merge 3 commits into
mainfrom
domtree-wto2
Open

tlively wants to merge 3 commits into
mainfrom
domtree-wto2

Conversation

@tlively

@tlively tlively commented Oct 6, 2026

Copy link
Copy Markdown
Member

Add src/cfg/wto.h with WeakTopologicalOrdering (WTO) and WTOWorklist built on top of DomTree. In a reducible CFG ordered in reverse postorder, every cycle is a natural loop headed by a block that dominates all blocks in the cycle, allowing a Bourdoncle Weak Topological Ordering to be constructed directly from the dominator tree and natural loops of the CFG.

Include unit tests in test/gtest/wto.cpp and TODO comments noting follow-on optimizations.

Add `src/cfg/wto.h` with `WeakTopologicalOrdering` (`WTO`) and `WTOWorklist` built on top of `DomTree`. In a reducible CFG ordered in reverse postorder, every cycle is a natural loop headed by a block that dominates all blocks in the cycle, allowing a Bourdoncle Weak Topological Ordering to be constructed directly from the dominator tree and natural loops of the CFG.

Include unit tests in `test/gtest/wto.cpp` and `TODO` comments noting follow-on optimizations.
@tlively
tlively requested a review from a team as a code owner October 6, 2026 07:06
@tlively
tlively requested review from kripken and stevenfontanella and removed request for a team October 6, 2026 07:06
@kripken

kripken commented Oct 6, 2026

Copy link
Copy Markdown
Member

Bourdoncle

Wait, I thought you were saying we didn't need Bourdoncle's algorithm in the end?

@tlively

tlively commented Oct 6, 2026

Copy link
Copy Markdown
Member Author

Bourdoncle defined weak topological ordering in the same paper where he introduced his algorithm to compute it. We're using his definition of weak topological ordering, but not his algorithm.

@tlively

tlively commented Oct 6, 2026

Copy link
Copy Markdown
Member Author

Hahaha I'm not sure I've seen a clang crash on CI before

Comment thread src/cfg/wto.h Outdated
// parenthesized into nested cycles. The first element of each cycle is its
// "head" (loop header), and the ordering satisfies two properties:
//
// 1. Every non-cycle edge u -> v goes forward in the flattened ordering

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

What is a "non-cycle edge"? I can imagine two things

  1. An edge that does not return to the head, i.e., does not literally cycle
  2. An edge that goes outside of the loop, i.e., to places that are not in the cycle

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.

Any edge that is not a backedge, i.e. does not go to the head of an enclosing cycle.

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 tightened up this definition.

Comment thread src/cfg/wto.h
for (auto* pred : blocks[h]->in) {
Index p = pred->contents.index;
if (dominates(h, p)) {
nodes[h].isLoopHeader = true;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I follow this up to here. The worklist processed on line 173, however, is unclear to me. Maybe add some comments on what is happening here?

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants