I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.
I’m not sure how far you can push the generality of the iongraph algorithm. My gut is that it could be made to work somewhat well for any control flow graph with reducible control flow, but I expect there would be many complications.
To get more precise, we benefit from knowing the nesting depth of each block. This plus reducible control flow is enough to reliably find loops. We also know exactly which edges are loop backedges; it’s easiest when these are explicitly annotated but perhaps it would be possible to derive that info from other loop info. (In Ion we have a dedicated “backedge block” per loop, which makes it obvious what we should do, but which other compilers likely wouldn’t have.)
There are also a bunch more available information channels that this doesn’t use that could communicate more information. Color, shape, pattern line type, “backdrops”/groups could all be implemented to provide additional visual clarity on any range of parameters you might care about.
I used to use the dcc application Nuke and it had some very complex graphs but the different nodes were all color coded so zooming out you could get a good idea of what was happening where just from the average color of a section.
It didn’t have an auto layout algo as good as this though.
What I really like about the article is the reflection on the limits of optimization. Optimization gets you mostly OK results most of the time, but there will always be pathological cases where optimization gives you bad results, and there’s often room for drastic improvements of you’re allowed to make stronger assumptions.