[llvm-dev] Testing utility for building and updating CFG

Jakub (Kuba) Kuderski via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 27 15:31:31 PDT 2017


Hi folks,

I’m working on adding an API for incremental updates to DominatorTree and I
noticed that there isn’t a simple way to quickly build and update CFG (just
for testing) -- one has to either build CFG programmatically, or write IR
by hand and manually map pointers to basic blocks. The downside is that it
tends to be pretty verbose and not easy to update (e.g. adding a new edge
often involves changing the type of terminator instruction).

My idea is to create a simple format for building arbitrary CFG’s and new
utilities for updating it.

It can look something like this:
b ModuleName FunctionName // Build module ‘ModuleName’ with a single

                         // function ‘FunctionName’.

a entry if                // Add new basic blocks (entry and if) and

                         // connect them with an edge.

a if if.then              // Add new basic block (if.then) and create

                         // an edge from if to if.then

a if if.else

a if.then foo

a if.else foo

a bar                     // Add a new block bar, but don’t create

                         // any edges.

e                         // Finish constructing initial CFG

i foo bar                 // Insert and edge from foo to bar.

d if if.then              // Delete the edge from if to if.then.

i if bar                  // Insert an edge from if to bar.



Under the hood, the utility would build IR with just switch instructions.

Then you could assign it to a string and use in a unit test:

CFGBuilder B(MyString);

Function *F = B.getFunction();

…

while (!B.finished()) {

   Update U = B.applyNextUpdate(); // B changes the CFG.

// U stores type of update (insertion/deletion) and a pair of BB’s

// (From and To).

   doSomethingWithTheUpdate(U);

}

Other CFG passes (e.g. LoopInfo, NewGVN) could also use it for testing. It
would be also possible to hook it up to a fuzzer at some point in the
future.

What do you think about having such a utility in llvm?
~Kuba

-- 
Jakub Kuderski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170627/19666de3/attachment.html>


More information about the llvm-dev mailing list