dblaikie added a comment. In D83088#2224297 <https://reviews.llvm.org/D83088#2224297>, @nhaehnle wrote:
>> 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. Yeah, sorry, I did see it - but didn't follow it in sufficient detail to understand the motivation/tradeoffs so well. (I do usually prefer to keep the design discussion on the design discussion threads, before worrying about the code specifics - but sometimes hard to understand it without code) >> 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. Not sure I follow - could you give an example of a graph where the GraphTraits concept of the Graph and the CfgTraits concept of the graph (or, perhaps more importantly - features of the graph/API surface area/properties you can expose through the CFG API/concept/thing but not through GraphTraits? > 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. I'm totally open to discussing making APIs more usable, for sure - though I'm thinking it's likely a concept (like containers in the C++ standard library) might be the better direction. Perhaps some code samples showing how one would interact (probably not whole algorithms - maybe something simple like generating a dot diagram for a graph) with these things given different APIs (traits, concepts, and runtime polymorphism) - and implementations of each kind too. 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
