Interprocedural slicing using LLVM

Hello,

I am curious to know if LLVM offers any passes to do interprocedural slicing, I need to eliminate most of the computations(possibly all, if they don't influence the control flow), but the control flow of the program should be maintained at all cost. I did see an optimization pass to print the CFG of a function without its body to a dot file, but I am interested in generating the source code which gets printed to a dot file.

Thanks,
Amruth

Hello,

I am curious to know if LLVM offers any passes to do interprocedural slicing, I need to eliminate most of the computations(possibly all, if they don't influence the control flow), but the control flow of the program should be maintained at all cost. I did see an optimization pass to print the CFG of a function without its body to a dot file, but I am interested in generating the source code which gets printed to a dot file.

There are two static backwards slicing passes for LLVM.

The first is a partial implementation I wrote for a course project. The code is in the giri project:

svn co https://llvm.org/svn/llvm-project/giri/trunk giri

The Giri code runs with an older version of LLVM and probably needs some TLC. It also only backtracks until it hits a load; additional code must be written to backtrack further to find potentially reaching stores.

The second option is to use some code written by Jiri Slaby at https://github.com/jirislaby/LLVMSlicer. I believe his implementation is a complete static backwards slicer, but I haven't used it myself, so I don't know it's quality or what version of LLVM it uses.

I think someone at UW-Madison may have an implementation as well; I'll contact that person and see.

-- John T.

Hi,

  1. How can I report a bug or commit a patch to the giri progject? I doubt this central commit list is the right place.

  2. Are you still maintaining the giri project any more?

Thank you.

L

I think posting to llvmdev is fine for now. However, I think it would be better if we just gave you commit access so that you can make changes directly. Would you like commit access? Well, we never really started maintaining the giri project. We began the work of releasing our code by creating the giri project and adding some of our slicing code to it because people kept asking us for a copy. We really haven’t started a concerted effort to make it a “real” LLVM sub-project (like SAFECode, for example) because a) one of the primary contributors is finishing his Ph.D., and b) we weren’t sure if there was a sufficient community of users that would use it and help us maintain it. So, if you’d like to update giri or provide bug fixes or what not, I can give you commit access, and you can have at it. The only thing we ask is that the code be licensed under the University of Illinois open source license (the BSD-style license that LLVM uses). – John T.

John,

Thanks for your quick reply.

Firstly, I’d like to employ a slicer for our benchmarking work (in one word, reducing the long-time irrelevant computing). I find the giri project and the LLVMSlicer[1]. However, the giri doesn’t seem a complete implementation to me. I admit that I have not finished reading document/discussion, e.g. the previous threads in this mailing list. While the latter has no documents/comments, which is of great importance to a beginner.

Secondly, I’m not an actual compiler guy although I’m trying to. If any of you who participated the giri project would like to direct me to write a full, generic and robust slicer for LLVM, I’m more confident to work on it.

Last, in FindFlow.h:67, is the code correct? I suppose it should be:

  • std::vector<const Function *>::iterator FE = Targets.begin();

  • std::vector<const Function *>::iterator FE = Targets.end();

Regards.

L

[1] https://github.com/jirislaby