[PATCH] D83088: Introduce CfgTraits abstraction

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar added a comment.

Hi Nicoali,

In D83088#2227151 <https://reviews.llvm.org/D83088#2227151>, @nhaehnle wrote:

> ...
> Take a look here for example: https://github.com/nhaehnle/llvm-project/blob/715450fa7f968ceefaf9c3b04b47066866c97206/llvm/lib/Analysis/GenericConvergenceUtils.cpp#L499 -- this is obviously still fairly simple, but it's an example of printing out the results of an analysis in a way that's generic over the underlying CFG and SSA form. A statically polymorphic wrapper is here: https://github.com/nhaehnle/llvm-project/blob/715450fa7f968ceefaf9c3b04b47066866c97206/llvm/include/llvm/Analysis/GenericConvergenceUtils.h#L569
>
> The simple example might be bearable writing as a template, precisely because it's simple -- so only looking at simple examples is unlikely to really capture the motivation. Really what the motivation boils down to is stuff like this: https://github.com/nhaehnle/llvm-project/blob/controlflow-wip-v7/llvm/lib/Analysis/GenericUniformAnalysis.cpp -- I don't fancy writing all this as a template.
>
> Thid motivation would essentially go away if C++ could type-check against traits in the way that Rust and other languages like it can -- but it can't, so here we are.

Based on your description and the DomTree patches, if I understand correctly, the primary motivation is to facilitate writing CFG-representation-agnostic algorithms/analyses (e.g., dominators, divergence, convergence analyses), such that you can later lift the results back to the representation-aware types? If that's correct, I support the overall goal. Having spent probably ~weeks wrangling with domtree templates, this sounds like something that could simplify life a lot and potentially cut down on compilation times & sizes of llvm binaries.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83088/new/

https://reviews.llvm.org/D83088