Double monotone chains for PDR

[gzz2000]

Summary

Hi OpenROAD maintainers,

This PR integrates the double monotone chains algorithm described in "Provably Optimal Planar Pareto Nearest Neighbor Search with Double Monotone Chains" (Guo et al, DATE'26) for Prim-Dijkstra in OpenROAD.

The algorithm is output-optimal, 39x faster than brute force and 1.3x faster than the lossy Guibas-Stolfi algorithm.

Type of Change

• New feature (new algorithm)

Impact

No behavior is expected to change. The algorithm is a drop-in replacement. Speed-up can be observed in large net Steiner tree generation.

Verification

• I have verified that the local build succeeds (./etc/Build.sh).
• I have run the relevant tests and they pass.
• My code follows the repository's formatting guidelines.

• I have included tests to prevent regressions.
• I have signed my commits (DCO).

Related Issues

N/A

[github-actions]

Welcome to OpenROAD! Thanks for opening your first PR.
Before we review:

• Contribution Guide: https://openroad.readthedocs.io/en/latest/contrib/GettingInvolved.html
• Build Instructions: https://openroad.readthedocs.io/en/latest/contrib/BuildWithCMake.html

Please ensure:

• CI passes
• Code is properly formatted
• Tests are included where applicable
  A maintainer will review shortly!

[gemini-code-assist]

Code Review

This pull request replaces the nearest neighbor search algorithm in pd.cpp with the double monotone chains algorithm to improve performance. The review feedback focuses on ensuring deterministic sorting by using std::tie with secondary coordinate keys, improving vector initialization readability by avoiding double resizing, and replacing the non-standard bitwise NOT operator (~j) with standard index checks (j >= 0).

[maliberty]

Fails to compile

[2026-09-07T16:38:56.048Z] src/stt/src/pdr/src/pd.cpp:67:12: error: no matching function for call to 'tie'
[2026-09-07T16:38:56.048Z]    67 |     return std::tie(pts[i].getX(), pts[i].getY()) < std::tie(pts[j].getX(), pts[j].getY());

Is the 39X improvement measured against the current code?

[gzz2000]

@maliberty The error was introduced by Gemini code review. It should be fixed now. Sorry about that!

39X is measured against the current get_nearest_neighbors implementation on 10K degree nets.

[maliberty]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-08T04:56:33.134858Z	9342d14	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[maliberty]

There are various test failures you can see in pr-head or pr-merge. Apparently this isn't just a speed up. Perhaps it affects the structure of the returned result?

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9342d14df5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Batch equal-x terminals before walking the chains

When many terminals share an x coordinate, this comparison retains every equal-x predecessor, and the sweep processes those terminals individually. The subsequent chain walks consequently connect every pair on that vertical line—for four aligned terminals this emits six edges instead of the three Pareto-neighbor edges—making both neighbor storage and buildSpanningTree work Θ(k²). Large aligned high-fanout nets can therefore consume excessive memory or stall, defeating the output-optimal replacement; equal-x terminals need explicit degeneracy handling rather than entering the sweep one by one.

Useful? React with 👍 / 👎.

[gzz2000]

I will look into them.

[maliberty]

Any update?

[gzz2000]

Hi @maliberty, sorry for the long delay (I was busy for a conference deadline). I will look into the bugs as well as your new PR.

[maliberty]

Replaced by #11602