nhaehnle added a comment. > Not sure that's the best place to be designing this fairly integral and > complicated piece of infrastructure from, but hoping we can find some good > places/solutions/etc.
I sent an email to llvm-dev several weeks ago, but things seem to have moved here. Either way is fine with me. > But I guess coming back to the original/broader design: What problems is this > intended to solve? The inability to write non-template algorithms over > graphs? What cost does that come with? Are there algorithms that are a bit > too complicated/unwieldy when done as templates? > If it's specifically the static/dynamic dispatch issue - I'm not sure the > type erasure and runtime overhead may be worth the tradeoff here, though if > it is - it'd be good to keep the non-dynamic version common, rather than now > having GraphTraits and CfgTraits done a bit differently, etc. It's not just over graphs, but taking SSA values into account as well -- that is the key distinction between GraphTraits and CfgTraits. The most immediate problem is divergence analysis, which is extremely complex and difficult to get right. If I had tried to fight the accidental complexity that comes with attempting to write such an algorithm as C++ templates in addition to the inherent complexity of the algorithm at the same time, I'm not sure I would have been able to produce anything workable at all. Frankly, I suspect that our dominator tree implementation also suffer because of this, though at least dominator trees are much more well studied in the academic literature, so that helps keep the inherent complexity under control. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83088/new/ https://reviews.llvm.org/D83088 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
