[mcmf] Pack edges inline into a CSR adjacency

[devin-ai-integration]

Summary

Data-oriented rewrite of the adjacency layout in mcmf.hpp (all three of MCMF_SSPA, MCMF_Dinic, Dinic), motivated by benchmarks showing the old std::vector<std::vector<int>> adj + shared edges array pays two dependent random loads per scanned edge:

old: adj[u] -> heap-allocated vector of edge ids -> edges[e].{dest,cap,cost}
new: csr[adj_start[u] .. adj_start[u+1]) with edge_t{dest, rev, cap[, cost]} stored inline

The staged edge list (input, with per-edge net flow) is the source of truth: each solve pack()s it into the scratch CSR (O(N+M), free relative to the solve) and unpack()s flows back afterwards, so add_edge works freely between solves. add_edge returns an edge id and flow_t flow(int id) reads back net flow (for add_bi_edge, in [-rev_cap, cap]); the new verify solutions use it to reconstruct matchings. Since forward/reverse edges are no longer at e/e^1, each CSR record carries a rev index.

Benchmarks (g++-15 -O2, seeds fixed, 3 trials each; Dinic<int>/Dinic<int64_t>):

• bipartite matching (L=R=200k, deg 6): ~1.3x vs old layout
• random sparse (N=200k, M=1M): ~1.3x
• 700x700 grid: ~1.5x
• MCMF_SSPA assignment (5000+5000, deg 30): ~1.3x

Also benchmarked but not adopted:

• CSR of edge-ids only (keeping the shared edge array): ~1.0x — inlining the payload is the actual win, not flattening the vector-of-vectors.
• vector<vector<edge_t>> with inline payload: ties CSR on unstructured graphs (0.9–1.05x) but loses 1.1–1.25x on grid-like graphs, where the single contiguous allocation keeps consecutive nodes' edges on shared cache lines.
• index/SoA layouts for lct.hpp: 0.86–0.99x — splay touches every field of a node, so splitting fields only adds cache lines.

Adds Library Checker verification: verify/bipartitematching.test.cpp (Dinic + flow() readback) and verify/assignment.test.cpp (MCMF_SSPA with costs shifted by 1e9 to satisfy the nonnegative reduced-cost precondition); both AC locally in the normal and sanitizer environments.

Link to Devin session: https://app.devin.ai/sessions/13b190fd3b54418395ae04b4e3aaa6e1
Requested by: @ecnerwala

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[beta-devin-ai-integration]

Devin Review found 1 potential issue.

View 1 additional finding in Devin Review.

[beta-devin-ai-integration]

🟡 Min-cost flow solver crashes when its layered-augmentation routine is used on its own

The min-cost Dinic solver's augmentation routine never prepares its internal edge storage (missing build() call at src/mcmf.hpp:266-267), unlike the plain max-flow solver which does, so calling it directly reads memory that was never set up and the program crashes or misbehaves.
Impact: Users who invoke the min-cost solver's per-phase routines directly (rather than the combined solve entry points) hit undefined behavior instead of getting a correct answer.

Missing lazy build in MCMF_Dinic::dinic while Dinic::dinic has it

After this PR the adjacency is packed lazily by build(). Dinic::dinic calls build() at src/mcmf.hpp:397, and MCMF_Dinic::all_flows/max_flow call it at src/mcmf.hpp:294 and src/mcmf.hpp:306, but MCMF_Dinic::dinic (src/mcmf.hpp:266) does not. If it (or dijkstra) is invoked before any solve, adj_start is empty, so adj_start[cur] / adj_start[cur+1] in the BFS loop (src/mcmf.hpp:276) index an empty vector and it.assign(adj_start.begin(), adj_start.end()-1) (src/mcmf.hpp:286) forms an out-of-range iterator. Previously these methods worked standalone since the adjacency was materialized in add_edge. The same gap applies to MCMF_SSPA::dijkstra/path and to flow(), which is const and therefore cannot build either.

(Refers to lines 266-267)

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[github-actions]

GCC Code Coverage Report

📂 Overall coverage

Metric	Coverage
Lines	🟡 7704/9366 (82.3%)
Functions	🟢 1016/1120 (90.7%)
Branches	🟡 6115/7805 (78.3%)