Speed up TopoSort by 2.7-3.3x.

[rmlarsen]

The main implementation in TopoSort::sort_worker is 11-12x faster. Overall, the complete sequence of building the graph and sorting is about 2.7-3.3x faster for the circuit I am working on. The overall impact in e.g. the replace_const_cells optimization pass is a ~35% speedup. End-to-end impact on our synthesis flow is about 3.3%.

Flame graph, zoomed on replace_const_cells, before:

Flame graph, zoomed on replace_const_cells, after:

Topdown view before:

Topdown view after:

[rmlarsen]

What are your thoughts on this PR? I could back out the unrelated formatting changes in utils.h, if so desired.

[Ravenslofty]

seems good to me.

[rmlarsen]

OK, I got rid of the needless formatting changes in kernel/utils.h. PTAL.

[rmlarsen]

It looks like the test latches.ys in the xilinx directory is failing. Investigating.

[rmlarsen]

Fixed. BTW: I realized that this code is somewhat brittle, since the sort order in map and set for some uses of TopoSort depends on the sort order of pointers. This is generally a bad code smell, since it tends to make code non-deterministic.

[rmlarsen]

OK, It finally passed. :-) PTAL.

[rmlarsen]

Trimmed a little fat off my implementation of node(). This speeds the overall topological sorting up by another 10% in my case.

[Ravenslofty]

In case you're wondering what's blocking this and #3975, I'd like somebody else to look over and approve it before I merge it, because I'm unfamiliar with the RTLIL internals; perhaps @mmicko?

[rmlarsen]

In case you're wondering what's blocking this and #3975, I'd like somebody else to look over and approve it before I merge it, because I'm unfamiliar with the RTLIL internals; perhaps @mmicko?

Yeah, no worries. It's always good to have more eyes on it.

[rmlarsen]

@Ravenslofty any updates from today's meeting?

[povik]

The code got less readable, unfortunately, but I suppose that's the price we ought to pay. Thanks @rmlarsen!

[povik]

We could opt for a non-recursive algorithm (a code example I have at hand), but that might not be producing the sort order code users expect, especially if they supply the C template argument.

[rmlarsen]

Thanks! Yeah, I've sometimes written it non-recursively, but in the profile it doesn't look like the recursion is a problem. One potential issue for large graphs is max allowed stack size, of course.