similar to: [LLVMdev] Extracting Single-entry single-exit Regions into functions

Tobias, Thanks for taking the time to summarize all this. It's a great writeup. I'm moving the thread to llvm-dev. My responses below. On May 21, 2012, at 5:06 AM, Tobias Grosser <tobias at grosser.es> wrote: > First of all some information about the RegionInfo pass: > > ======================================================================= > The very first paper I

Hi Tobias, Thanks so much for the quick response. Your approach fixes the issue. On a bigger context, would it make more sense to make the region exit part of the region? For example, a while loop gets lowered down to LLVM IR contains while.cond, while.body and while.end. If one tries to use RegionInfo as a substitute for structural analysis, she might think while.end should belong to

Hi Fellows, I notice an unexpected behavior in RegionInfo's block_iterator. Consider the following situation: a user creates her own region containing just a single basic block TheBB, then tries to have the block_iterator to print a DFS traversal of the region. The expected behavior should be that only the single basic block TheBB will be printed, but the real behavior is that

On 01/26/2011 07:50 PM, Vu Le wrote: > I guess I didn't have a clear question. > > Suppose we have BB1 and BB2 both point to BB3. > BB1 has variable x. BB2 also as variable x. > BB3 will have PHINode for x with 2 value from BB1 and BB2. > BB1 BB2 > \ / > BB3 > > Now if BB1 and BB2 is extracted into a function > (using ExtractCodeRegion), they

I guess I didn't have a clear question. Suppose we have BB1 and BB2 both point to BB3. BB1 has variable x. BB2 also as variable x. BB3 will have PHINode for x with 2 value from BB1 and BB2. BB1 BB2 \ / BB3 Now if BB1 and BB2 is extracted into a function (using ExtractCodeRegion), they will be replaced by a basic block called codeRepl (which has a call to the extracted

Hi Tobias, If the PHI node at exit block of region R has multiple inputs from the R, I split the exit block into 2. The first block contains all PHI nodes whose input are all from the region. The second is the new exit node. All branches (outside R) to the old exit now point the new exit. All regions whose exit is the old exit are also updated with the new exit node. It works like a charm.

Last time I asked here about superblocks (which we were using in the first version of ThreadSanitizer instrumentation) Tobias Grosser has suggested to use RegionInfo: did you have a look at the RegionInfo pass? It currently detects some kind of refinded SESE regions. I use them in Polly and as far as I know the Intel OpenCL SDK also uses them in some way. It is not SEME, but it may

Hi all, I have problem with ExtractCodeRegion (CodeExtractor.cpp). My original program is as follows. bb: ... %tmp.15 = load %struct.MYSQL_ROWS** %3, align 4 ... bb1: ... %tmp.1 = load %struct.MYSQL_ROWS** %6, align 4 ... bb4: ; preds = %bb1, %bb, %entry %tmp.0 = phi %struct.MYSQL_ROWS* [ null, %entry ], [ %tmp.15, %bb ], [ %tmp.1, %bb1 ]

Why not use the "standard" algorithm for detecting SESE-regions and building a program structure tree? It should handle everything you want. It also becomes much simpler to specify a connected SESE-region by entry/exit edges, while a disconnected region is specified by entry/exit blocks. Only defining regions on blocks is not enough to be able to quickly determine how to replace/move a

On Fri, May 2, 2014 at 5:30 PM, Tobias Grosser <tobias at grosser.es> wrote: > On 03/05/2014 00:15, Paul Vario wrote: > >> Hi Tobias, >> >> Thanks so much for the quick response. Your approach fixes the >> issue. >> On a bigger context, would it make more sense to make the region >> exit >> part of the region? For example, a while

Hi, I'm trying to solve a problem from StructurizeCFG not actually handling regions with multiple exits. Sample IR attached. StructurizeCFG doesn't touch this function, exiting early on the isTopLevelRegion check. SIAnnotateControlFlow then gets confused and ends up inserting an if into one of the blocks, and the matching end.cf into one of the return/unreachable blocks. The input to

Hi Johannes, On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert < doerfert at cs.uni-saarland.de> wrote: > Hey Utpal, > > First of, I think you made nice process here and have some very good > ideas of what we could do in the future. > > [NOTE: I CC'ed some people that have shown interest in this topic but I > might have forgotten some, therefor I also added the

In the design the LLVM passes always directly communicate with PolyhedralInfo, this requires Polly tightly integrate in to LLVM. If we do not want a tight integration, we can do the following: 1. Introduce an abstract memory dependency query interface, like AliasAnalysis 2. I remember LLVM had already have dependency analysis, this can be the default implementation of the memory dependency query

Dear Community, I would like to summarize my work till date for GSoC 2016. Till the current phase of my project, I have mostly focused on developing the necessary infrastructure to use analysis results from Polly in LLVM. Initial plan as mentioned in the proposal: For the first month:- 1. Decouple ScopInfo pass from Polly’s pass chain and provide capability to create SCoP(Static

On 03/23, Hongbin Zheng wrote: > Hi Johannes, > > On Mon, Mar 21, 2016 at 6:35 PM, Johannes Doerfert < > doerfert at cs.uni-saarland.de> wrote: > > > Hey Utpal, > > > > First of, I think you made nice process here and have some very good > > ideas of what we could do in the future. > > > > [NOTE: I CC'ed some people that have shown

Hey Utpal, First of, I think you made nice process here and have some very good ideas of what we could do in the future. [NOTE: I CC'ed some people that have shown interest in this topic but I might have forgotten some, therefor I also added the llvm-dev list.] For the upcoming GSoC proposal we should slow down a little bit and reevaluate our goals. After talking to a couple of LLVM and

On 07/20/10 02:24, Jianzhou Zhao wrote: > Hi, > > Is the structural analysis pass discussed in > http://comments.gmane.org/gmane.comp.compilers.llvm.devel/30213 still > available to download? Hi, I recently proposed the RegionInfo pass for LLVM. It is not a complete structural analysis pass, however it builds an sese region tree and can probably be extended to classify the

Hi ether, Your suggestion is appropriate with respect to LLVM framework. However, I am not aware of such a common interface for Dependence Analysis as there is one for AliasAnalysis. The current plan is to provide the new Dependence Analysis interface that can be used when the other analysis engines fail to provide a concrete result. I do not want to overestimate things by proposing such a common

On 01/08/10 14:20, ether wrote: > sorry that i forgot to change the subjuect > > > hi all, Hi ether, now a kind of more complete answer. > On 2010-1-7 0:11, John Mosby wrote: >> In LLVM we could add support for generalized CFG regions and >> RegionPasses. A region is a part of the CFG. The only information we >> have is, that it has one entry and one exit, this

Hi , It will be good ,If you get us the sample that assert. Thanks ~Umesh On Tue, Jul 31, 2012 at 11:40 AM, 田中 太郎 <dontforgettobringatowel at live.jp>wrote: > > Hi all, > > I ran across an assertion failure while using region analysis in my passes. > I get the same thing when doing: opt -regions -analyze > > [...] > [1] entry => if.end > End region tree