growRegion() does not scale in code with BBs with a very large number of edges.
In such code growRegion() becomes a compile-time bottleneck, consuming 60% of
the total compilation time.
This patch adds a limit to the complexity of growRegion() by incrementing a counter
in each iteration. We bail out once the limit is reached.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Nit: can you please rephrase the commit message, last statement: the patch (correctly) doesn't place a limit on time (which would be non-deterministic), rather, it places a limit on the number of Blocks visited (deterministic).
The patch LGTM, but I'm curious, why do we end up with a bazillion edges, like what property do the blocks pointed at the edges have, like are they all going to an exit block, or in any case, is this a meaningful pattern - maybe we could avoid placement via the Hopfield Network, and instead do something simpler (and maybe it benefits the rest of the allocation)?
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
793 | You could just take Visited out of its conditional compilation block and compare it to GrowRegionComplexityBudget. I realize Visited is incremented less often than Budget is currently decremented, but it does achieve the same goal? |
llvm/lib/CodeGen/RegAllocGreedy.cpp | ||
---|---|---|
793 | Yes, it would be similar I guess, but I think it is probably best to keep the counters separate as their purpose is different. |
You could just take Visited out of its conditional compilation block and compare it to GrowRegionComplexityBudget. I realize Visited is incremented less often than Budget is currently decremented, but it does achieve the same goal?