search for: graphdiff

...t; > What's stopping you from implementing it for clang CFG? I looked at the > code and it seems like your new implementation handles it. > The link I sent is a diff of two branches, and I changed a lot of code yesterday. Initally, I "bruteforced" my way through generalizing GraphDiff and related classes, and that patch looked anything but appealing. Thanks for your comments by the way, to this and the related patches! > 2. I didn't really manage to understand the logic for GraphDiff. What does >> it really do in IDFCalculator's context? I dag out the patch[2...

...FCalculator::setLiveInBlocks, and the file header seems to >> confirm that it's an implementation specific thing. Could I get away >> restricting the clang::CFG tailored version to not contain this function? >> >> 2. I didn't really manage to understand the logic for GraphDiff. What >> does it really do in IDFCalculator's context? I dag out the patch[2] that >> added an extra constructor to use a snapshot of the CFG, but it seems to be >> unused. Is it also unlikely that we find any use for this? Mind you, the >> patch size grew a lot because...

...1], but I found no references to IDFCalculator::setLiveInBlocks, and the file header seems to confirm that it's an implementation specific thing. Could I get away restricting the clang::CFG tailored version to not contain this function? 2. I didn't really manage to understand the logic for GraphDiff. What does it really do in IDFCalculator's context? I dag out the patch[2] that added an extra constructor to use a snapshot of the CFG, but it seems to be unused. Is it also unlikely that we find any use for this? Mind you, the patch size grew a lot because I also "templatized" Graph...

Hi Jakub, On Tue, Jul 7, 2020 at 6:25 AM Jakub (Kuba) Kuderski <kubakuderski at gmail.com> wrote: > There's a lot of heavily templated code in generic DomTee construction/updater, MemSSA updater, and GraphDiff that has become really hard to modify. For the context, Alina (cc'd) was recently looking into making the domtree code work with 'CFG views'; the basic idea is to take a concrete CFG and a series of updates and create a view over this CFG, as if the updates were applied, add more update...

Hi all, This is a request for comment on a series of patches which introduce a new way of writing algorithms that are generic over different types of CFG. What is this? ============= This series of patches introduces a set of classes and templates for: 1. Working on basic blocks and values generically, in particular with the same algorithm implementation on both LLVM IR and MachineIR (in SSA

Hi, As part of an ongoing work to extend the GraphDiff (this models a CFG view), I came across the need to have a common interface for accessing successors/predecessors in various IR units, such that a type such as `typename NodeT::succ_iterator` could be used in templated code. In particular, the need arose for BasicBlocks, MachineBasicBlocks, VPBlock...

...ly. Thanks, Alina On Mon, Mar 9, 2020, 4:16 PM David Blaikie <dblaikie at gmail.com> wrote: > > > On Mon, Mar 9, 2020 at 3:57 PM Alina Sbirlea via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> As part of an ongoing work to extend the GraphDiff (this models a CFG >> view), I came across the need to have a common interface for accessing >> successors/predecessors in various IR units, such that a type such as >> `typename NodeT::succ_iterator` could be used in templated code. >> > > I /think/ this can be achiev...

...ikie at gmail.com> wrote: >> >>> >>> >>> On Mon, Mar 9, 2020 at 3:57 PM Alina Sbirlea via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> As part of an ongoing work to extend the GraphDiff (this models a CFG >>>> view), I came across the need to have a common interface for accessing >>>> successors/predecessors in various IR units, such that a type such as >>>> `typename NodeT::succ_iterator` could be used in templated code. >>>> >&g...