pdn: Give pins stable order#8904
pdn: Give pins stable order#8904openroad-ci wants to merge 1 commit intoThe-OpenROAD-Project:masterfrom
Conversation
The order seems to matter for pdngen output so make it stable. See the updated tests. Signed-off-by: Martin Povišer <povik@cutebit.org>
| break; | ||
| } | ||
|
|
||
| std::sort(pins_.begin(), pins_.end(), [](odb::dbBox* l, odb::dbBox* r) { |
There was a problem hiding this comment.
warning: use a ranges version of this algorithm [modernize-use-ranges]
| std::sort(pins_.begin(), pins_.end(), [](odb::dbBox* l, odb::dbBox* r) { | |
| std::ranges::sort(pins_,, [](odb::dbBox* l, odb::dbBox* r) { |
| } | ||
|
|
||
| std::sort(pins_.begin(), pins_.end(), [](odb::dbBox* l, odb::dbBox* r) { | ||
| return std::make_tuple(l->xMin(), l->xMax(), l->yMin(), l->yMax()) |
There was a problem hiding this comment.
warning: no header providing "std::make_tuple" is directly included [misc-include-cleaner]
src/pdn/src/straps.cpp:14:
- #include <utility>
+ #include <tuple>
+ #include <utility>| std::sort(pins_.begin(), pins_.end(), [](odb::dbBox* l, odb::dbBox* r) { | ||
| return std::make_tuple(l->xMin(), l->xMax(), l->yMin(), l->yMax()) | ||
| < std::make_tuple(r->xMin(), r->xMax(), r->yMin(), r->yMax()); | ||
| }); |
There was a problem hiding this comment.
While sorting here does close the discrepancy between my local runs and the CI, @gadfort points out pins_ should be having a stable order by construction. The root cause for test flakiness might lie elsewhere
There was a problem hiding this comment.
My concern here is that this is only masking the issue, as far as I can tell the order of these boxes matches the order they are in the database. Have you checked that the ordering of these boxes in the database differs?
There was a problem hiding this comment.
Also, why not just use the compare provided by the database for sorting
There was a problem hiding this comment.
Have you checked that the ordering of these boxes in the database differs?
I take that as sorting pins_ using the dbCompare.inc comparator and checking if it's a no-op. I'll see
There was a problem hiding this comment.
I took a look, the order of pins_ appears to be the same between the bazel and cmake builds. So it's likely that you are changing something with the sort, but I don't believe this is where the instability comes from.
There was a problem hiding this comment.
I actually think a much more likely culprit might be the rtree storing the shapes. This would cause the order in which we write the shapes to the database to differ because the order in the tree is different.
|
replaced by #8963 |
The order seems to matter for pdngen output so make it stable. See the updated tests.