similar to: [LLVMdev] Reusing CFG structures

This proposal adds support for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at runtime. Path profiles enable precise enumeration of the sequence of basic blocks executed in order for a particular path. Using path

Hi all, I plan to improve the existing profiling support in LLVM for my master thesis. The goal is threefold: a) Implement more efficient instrumentation along the lines of [Ball94]. b) Implement and experiment with heuristic estimators as proposed in [Wu94]. c) Make profile information available in the backend machinery. We have a preliminary patch that achieves this by maintaining

Hello Kapil, I have implemented a static profiler for LLVM as a google summer of code project in 2009. I wrote it for the 2.4 branch, but the implementation never made into the tree. I have recently ported it to LLVM 2.8, but I haven't tested it. You can take a look at the code from: http://homepages.dcc.ufmg.br/~rimsa/tools/stprof-llvm.patch The implementation is based on Wu's

Thanks Andrei! I haven't read the paper. I would see whether this fulfills my requirements or whether I need to make any changes. --Kapil On Tue, Nov 2, 2010 at 12:43 PM, Andrei Alvares <logytech at gmail.com> wrote: > Hello Kapil, > > I have implemented a static profiler for LLVM as a google summer of > code project in 2009. I wrote it for the 2.4 branch, but the >

Hello Jeff, On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > My god! I would love a branch predictor! It would simplify many aspects of > my register allocator. The branch predictor of the implementation is not as accurate as the one from the paper, but it is close enough. Unfortunately, the branch predictor is a very expensive pass, because it relies on

My god! I would love a branch predictor! It would simplify many aspects of my register allocator. Second, I am surprised it did not make it into the tree. Since more is being done with register allocation as a while "RegAllocBasic" was just put in, I hope this is looked at again. Do you have a working svn copy? Also, could you send me a copy/link to that '94 paper off the list

Hi Jeff, There is an algorithm to build the dominator tree that is O(n2), where n is the number of nodes on the control flow graph. I believe exists another that is linear, but I don't which one of them is implemented in LLVM. The problem is that the branch predictor requires post dominance information. None of the LLVM basic passes require post dominance information (AFAIK), hence it is

You said it was expensive, but if you had to put a big-o estimate on it, what would it be? -Thanks Jeff Kunkel On Tue, Nov 2, 2010 at 8:54 PM, Andrei Alvares <logytech at gmail.com> wrote: > Hello Jeff, > > On Tue, Nov 2, 2010 at 9:17 PM, Jeff Kunkel <jdkunk3 at gmail.com> wrote: > > My god! I would love a branch predictor! It would simplify many aspects > of >

Hello all, I would like to participate in this year's Google Summer of Code and I am sending you a short description of my proposal. I have written the formal proposal already and if someone is interested I can send him the pdf. One of the open projects in the LLVM list is to enhance LLVM with static profiling capabilities. LLVM already provides a unified structure for writing pro

Hi, Dear Boissinot: 1. When I have irreducible CFG, I travel its nodes by DFS. search backedge for every node. After I finish one node, push it into a stack. [0, 1, 2, M] <---push. [0, 1, 2, M,...N] <---push. When resolving node M, find a edge from node N to node M, N is not in stack(M < N), It is a backedge. N is in stack(M > N), It is NOT a backedge.

2010/1/25 任坤 <hbrenkun at yahoo.cn>: > Hi: > > I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. > > 1. MachineDominatorTree *domintree = new MachineDominatorTree(); > domintree->runOnMachineFunction(mf); > > 2. Then travel mf one by one. > When domintree->dominates(next,current) is true, there is a backedge

Thank you, Nick. Yes, I have add getAnalysisUsage. As I know, some CFG is irreducible. At this time, Dominator Tree can not find some backedge. Is it means some MachineLoop is not be found? dominatorTree.jpg is a previous exmaple. best regards! renkun --- 10年3月9日，周二, Nick Lewycky <nicholas at mxc.ca> 写道： > 发件人: Nick Lewycky <nicholas at mxc.ca> > 主题: Re: [LLVMdev] Find

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

Hi:    I want to do some optimization on MachineLoop. So I want to get MachineLoopInfo from MachineFunction. I reference MachineLICM.cpp. So I try to write a pass in Target/mytarget directory. I find there is Error. llvm/include/llvm/PassAnalysisSupport.h:198: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = llvm::MachineLoopInfo]: Assertion

Hello, I am planning on contributing path profiling to LLVM by the end of August. I have written a document of what the interface to the path profiles would look like at that time. If someone has any amendments, I can incorporate them. http://www.cs.ualberta.ca/~pejic/PathProfiling.html Slobodan Pejic

Hi Vedant, I would like to clarify that the proposal does *intra-procedural* path profiling as described in [Ball96]. > > This proposal adds support for path profiling [Ball96] to LLVM. Path profiling compactly represents acyclic paths in a directed acyclic graph representation of the control flow graph of a routine. Instrumentation can be added to uniquely identify paths executed at

On Friday 10 July 2009 18:06, Slobodan Pejic wrote: > Hello, > > I am planning on contributing path profiling to LLVM by the end of > August. I have written a document of what the interface to the path > profiles would look like at that time. If someone has any amendments, I > can incorporate them. > > http://www.cs.ualberta.ca/~pejic/PathProfiling.html Slobodan, This

David Greene wrote: > On Friday 10 July 2009 18:06, Slobodan Pejic wrote: >> Hello, >> >> I am planning on contributing path profiling to LLVM by the end of >> August. I have written a document of what the interface to the path >> profiles would look like at that time. If someone has any amendments, I >> can incorporate them. >> >>

Hi! As the title suggests, I'd like to generalize llvm::IDFCalculator to be able to calculate control dependencies on clang's CFG. The issue is however, that many data structures it uses are "hardcoded" to use llvm::BasicBlock, and requires a lot of code to turn it into template arguments. I managed to pull this off by hammering the code until it compiled, and it works

On Apr 3, 2009, at 12:52 AM, Kshitiz Garg wrote: > Here is my formal proposal i have submitted in gsoc. Comments invited. > This sounds like a very interesting proposal. Many compilers clone loops and use dynamic checks to enforce invariants in one copy of the loop. Is this intended to be similar to that style of approach? -Chris > > About me: > > I am a final