similar to: [LLVMdev] a problem when using postDominatorTree

I'll try the trunk, as well as check my code again. If indeed it's not fixed, I'll try to post a triggering case here. Thanks for the advice~ Best, --Wenbin ----- Original Message ----- From: "Tobias Grosser" <grosser at fim.uni-passau.de> To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> Cc: <llvmdev at cs.uiuc.edu> Sent: Thursday, August

Wenbin Zhang wrote: > I'll try the trunk, as well as check my code again. If indeed it's not > fixed, I'll try to post a triggering case here. > Thanks for the advice~ > Did you run the -mergereturn pass (it might also be called UnifyExitNodes in the source code)? This is the pass that ensures that each function has exactly one basic block that returns control to the

Hi all, I'm using postDominatorTree to do some program analysis. My code works well for small tests, but when I run it on real applications, the following error occurs: Inorder PostDominator Tree: DFSNumbers invalid: 0 slow queries. [1] <<exit node>> {0,21} [2] %bb1 {1,2} [2] %bb {3,4} [2] %entry {5,6} [2] %bb8 {7,20} [3] %bb7 {8,9} [3] %bb2 {10,11}

On 08/05/2010 06:00 PM, John Criswell wrote: > Wenbin Zhang wrote: >> I'll try the trunk, as well as check my code again. If indeed it's not >> fixed, I'll try to post a triggering case here. >> Thanks for the advice~ >> > > Did you run the -mergereturn pass (it might also be called > UnifyExitNodes in the source code)? This is the pass that ensures

Many published analyses which build on post-dominance assume a canonical single-dominator-tree form induced by unifying all exits (and often adding a virtual edge from START to END). In contrast, it seems that the current LLVM post-dominator analysis only operates in a mode in which it generates a forest of post-dominator trees, with one rooted at each exit node. The problem this can cause is

Dear all, Is there a way to check whether we can go from A to B within a function when I'm writing a pass? Thanks. Best, --Wenbin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100827/8cf26762/attachment.html>

Hi folks, For the past month I’ve been working on improving the DominatorTree and PostDominatorTree in LLVM. The RFC that explains the motivations and plans can be found here: http://lists.llvm.org/pipermail/llvm-dev/2017-June/114045.html . Here’s a short summary of what changed upstream since posting it: - We switched from the Simple Lengauer-Tarjan algorithm for computing dominators

----- Original Message ----- From: "John Criswell" <criswell at illinois.edu> To: "Wenbin Zhang" <zhangwen at cse.ohio-state.edu> Cc: <llvmdev at cs.uiuc.edu> Sent: Friday, August 27, 2010 5:09 PM Subject: Re: [LLVMdev] how to check whether from basicblock A we can go to basicblock B within the same function? > Wenbin Zhang wrote: >> Dear all,

Wenbin Zhang wrote: > Dear all, > Is there a way to check whether we can go from A to B within a > function when I'm writing a pass? I assume you are asking whether control flow can pass from BasicBlock A to BasicBlock B. In that case, yes: all you need to do is look at the terminator instruction of BasicBlock A and see if it can branch to BasicBlock B. There's a new indirect

George Baah <georgebaah at gmail.com> writes: > Hi Guys, > > I saw in the API that DominanceFrontier has been deprecated. Is this > for real? > I have read the computational issues but shouldn't that be left to the > users of llvm? > My concern is I am writing a Control Dependence module that uses > Dominance-Frontier information. > Getting rid of Dominance

Hi, I compile a .cpp with cmd: clang++ -emit-llvm -c -g -O0 -w pbzip2.cpp -o pbzip2.bc -lbz2 llvm-dis pbzip2.bc One function in .cpp is consumer_decompress. However, I look inside pbzip2.ll. The function name is changed to "define i8* @_Z19consumer_decompressPv(i8* %q) #0 {" Why clang adds a "_Z19" prefix and "Pv" suffix? Thanks,

Hi all, While working on a loadable Alias Analysis module pass, I'm running into the following issue: I'm finding my pass queried for results after it has had 'releaseMemory' called on it and its dependencies, but before runOnModule is called again (on my pass or its deps). As you might expect, this makes my pass rather unhappy (and I think correctly so). This happens with LICM

Thanks John, I modify my code to like this: bool XXX::ModulePass(Module &M){ .... LoopInfo &li = getAnalysis<LoopInfo>(fi); .... } Here fi is a Function* pointing to main(). Now when I run the pass, another error shows up: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*, llvm::Function&) [with AnalysisType = llvm::LoopInfo]: Assertion `ResultPass

Hi, I am dealing with very large datasets and it takes a long time to save a workspace image. The options to save compressed data are: "gzip", "bzip2" or "xz", the default being gzip. I wonder if it's possible to include the pbzip2 (http://compression.ca/pbzip2/) algorithm as an option when saving. "PBZIP2 is a parallel implementation of the bzip2

Hi all, Can we map an IR instruction to the correlated source code? Or, if I want to recognize an assignment statement in the source code, can we quickly find all the related IR instructions according to a 'store'? E.g., i = j +k + m[5] in IR will have some loads and some getelementptrs. Can we define which IRs are related to this assignment? Thanks. Regards, --Wenbin --------------

Hi all, I'm reading the language reference of LLVM here: http://llvm.org/docs/LangRef.html#i_getelementptr In the first example, it shows that the generated IR is supposed to be something like: %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13 But when I copied the code and compile it myself (using v2.7), I got five getelementptr instructions, which are just like the equivalent

Hi Guys, I saw in the API that DominanceFrontier has been deprecated. Is this for real? I have read the computational issues but shouldn't that be left to the users of llvm? My concern is I am writing a Control Dependence module that uses Dominance-Frontier information. Getting rid of Dominance Frontiers will put me in a tight spot. George -------------- next part -------------- An HTML

I think this assertion failure may be caused by the getAnalysisUsage(). Mine is like the following: class myclass : public ModulePass{ ... virtual void getAnalysisUsage(AnalysisUsage &AU) const { AU.addRequired<LoopInfo>(); } ... } Is it enough? Thanks! Best, --Wenbin ----- Original Message ----- From: Wenbin Zhang To: John Criswell Cc: llvmdev at

Hi Fellows, I am writing a pass that requires the DominatorTree pass. In the runOnFunction of my own pass, I call llvm::SplitBlock to split a block (%for.end) at it's first insert point. Then, when I dump my dominator tree immediately after, I can see the newly split %for.end.split, but its DFSNumIn and DFSNumOut are not properly updated in llvm::SplitBlock (i.e., still the initialized

On 03/07/2010 11:09 AM, Jochen Wilhelmy wrote: > Hi! Hi Jochen, > I'd like to find the point where the control flow joins after a branch. > > e.g. if I have the following function > > if (a< b) > foo1(); > else > foo2(); > bar(); > > Then the control flow splits at the basic block containing a< b with > a branch as terminator