similar to: [LLVMdev] Any passes that work on extended basic blocks?

As far as I know, there is none. Pretty much every analysis or transform on EBBs can be extended to work on the dominator tree, which is what LLVM prefers. Cameron On Apr 8, 2013, at 9:53 PM, Bill He <wh3 at rice.edu> wrote: > Hi all, > > I am trying to find a sample pass that works on extended basic blocks. Any suggestion or help is very much appreciated. > > Thanks in

I'm looking for a way to traverse machine basic blocks in a specific order. Basically I want all blocks that are predecessors to the current block to be traversed before the current block. I've looked at MachineDominatorTree but this doesn't traverse them in quite the way I want them to. Anyone know of a way to do this? Thanks, Micah -------------- next part -------------- An HTML

The reverse postorder iterator does what you want. It's defined in ADT/PostOrderIterator.h, and is used like this: ReversePostOrderTraversal<Function*> RPOT(&F); for (ReversePostOrderTraversal<Function*>::rpo_iterator RI = RPOT.begin(), RE = RPOT.end(); RI != RE; ++RI) <work here> Creating a ReversePostOrderTraversal is not cheap, because it first has to

Hi, Example on how to iterate over CFG, take a look at DominanceFrontier.cpp. You can further implement easily a traverse graph algorithm. On Tue, Mar 19, 2013 at 2:35 PM, Ashish Kulkarni < ashish-kulkarni at hotmail.com> wrote: > Hi LLVM Delveloper, > i've been working on LLVM and Clang to get basic block information. > The CFG supports Visitors (CFG.h) but i might

Hi LLVM Delveloper, i've been working on LLVM and Clang to get basic block information. The CFG supports Visitors (CFG.h) but i might want to ask that is there any code sample available so that i can get the things easily.. Regards, Kulkarni Ashish A. College of engineering, Pune India. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

On Tue, May 5, 2015 at 10:20 AM, Jingyue Wu <jingyue at google.com> wrote: > Hi Daniel, > > I presume you mean, instead of assigning function arguments distinct ranks > (http://llvm.org/docs/doxygen/html/Reassociate_8cpp_source.html#l00282), we > should group function arguments in favor of existing pairings. Existing = pairings reassociate already chose before *not* existing

Hello, I was wondering whether or not some behaviour that I am seeing is expected behaviour and that it has been designed like this, or not. A dominator relation is given by "if A dominates B", then all paths to B go through A. For example, take the CFG below (which is a directed graph (couldn’t make the arrow heads but ok.): A / \ B C \ / D | E We can construct

This is better suited to llvm-dev, so I'm directing it there. From: llvm-commits <llvm-commits-bounces at lists.llvm.org> on behalf of Qing Shan Zhang via llvm-commits <llvm-commits at lists.llvm.org> Reply-To: Qing Shan Zhang <qshanz at cn.ibm.com> Date: Sunday, August 19, 2018 at 10:10 PM To: "llvm-commits at lists.llvm.org" <llvm-commits at lists.llvm.org>

Patch for review. On Mon, Aug 21, 2017 at 11:45 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> wrote: > Ping. > > Still working on preparing code for review. Will have a patch for review > ready in the coming days. > > PL > > On Tue, Aug 15, 2017 at 12:06 PM Puyan Lotfi <puyan.lotfi.llvm at gmail.com> > wrote: > >> Hi, >> >> >>

Hi Weibo, I thought would be more efficient discussing here (I just saw that every info was replicated on both emails you were sending to me). I just run your example here on my working machine, and I didn't have any issues with the namespace. Just tell me one thing: which line (and flags) are you using when configuring and make your build llvm directory? Oh, and one more thing: what is on

Thanks for your reply, John. I am using opt to run my pass. Should opt by default link in the library? Would you please give me some idea on fixing it? Thanks! opt -load ../../../Debug+Asserts/lib/LLVMHello.dylib -hello < hello.bc > /dev/null My pass is just: #include "llvm/IR/Function.h" #include "llvm/Pass.h" #include "llvm/Support/raw_ostream.h" #include

Hi all, I am trying to traverse a dominator tree and have encountered a weird runtime exception: Here's my simple code: virtual bool runOnFunction(Function &F) { DominatorTree& DT = getAnalysis<DominatorTree>(); * DomTreeNode* rootNode = DT.getRootNode();* return false. } Here's the documentation page:

On 4/12/13 9:51 AM, Bill He wrote: > Thanks for your reply, John. > > I am using opt to run my pass. Should opt by default link in the > library? Would you please give me some idea on fixing it? Thanks! Odd. I would think that opt would have that pass linked in statically. I'm not sure why it's not working. Does anyone else have an idea? -- John T. > > opt -load

LLVMers, Is there any way to guarantee iteration of the basic blocks from top down or path to path? Currently it looks sort of semi-random, sometimes visiting loop heads first and other times loop tails, is there a way I can visit the BBs top down or path to path? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 4/11/13 10:30 PM, Bill He wrote: > Hi all, > > I am trying to traverse a dominator tree and have encountered a weird > runtime exception: > > Here's my simple code: > > virtual bool runOnFunction(Function &F) { > DominatorTree& DT = getAnalysis<DominatorTree>(); > > * DomTreeNode* rootNode = DT.getRootNode();* > return false.

Dear listers, a little off-topic: I am looking for and compare algorithms which can calculate "distance" or "similarity" between two gene lists with different lengths. Any paper, any implementation in R and any suggestion is welcome! Thanks, -- Weiwei Shi, Ph.D Research Scientist GeneGO, Inc. "Did you always know?" "No, I did not. But I believed..."

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,

Sorry, forgot to add group to CC. On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Cameron, > > To make it less vague, I would ideally like to traverse top down. I > believe what you suggested is what I want, I will have a look at it. > > Currently, I am iterating over the BBs in a Function, so > Function::iterator BBitr=F->begin(),