similar to: [LLVMdev] Make LoopBase inherit from "RegionBase"?

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 01/15/10 03:03, ether wrote: > hi, Hi, > about region class, i think provide some method to extract the top level > loop from a given region is useful in polly(our polyhedral optimization > framework), because the we are only doing optimization on the region > with loop. Hi ether, I think this should be implemented as a RegionFilter, that checks if a region contains a loop,

On 01/20/10 18:16, Jan Sjodin wrote: >> I think this should be implemented as a RegionFilter, that checks if a > >> region contains a loop, and that can be asked for further information. >> In general I do not think this kind of analysis belongs to a region, but >> as you proposed some kind of filter could be applied. In the short term >> the passes who need this

On 01/21/10 20:42, Jan Sjodin wrote: >>> Imo, a loop is simply a special kind of region, so a "filter" is perhaps the way to >>> go if you are interested in loops. Regions containing loops will have to be inspected >>> using the PST. >> >> Except loops that have multiple exits. they are not necessarily (single >> entry single exit) region, if

On 01/08/10 14:20, ether wrote: > sorry that i forgot to change the subjuect Hi ether, sounds interesting. Actually is/may be some kind of region. If you want you can have a look at the analysis, that I wrote. It is not yet finished, not completely documented and work in progress. However the first big comment might be interesting for you. Or seeing the results of opt -regions -analyze

On 01/13/10 00:56, Jan Sjodin wrote: > 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

On 01/13/10 05:09, Jan Sjodin wrote: > Hi Tobias > >> In general this approach saves a preliminary pass that has to insert new > >> bbs, to generate these edges. As we do not have to modify the CFG other >> passes like dominance information are still valid, and we do not have to >> create a lot of auxiliary bbs, to be able to detect all regions. This >>

On 01/20/10 18:05, Jan Sjodin wrote: >>>> bbs, to generate these edges. As we do not have to modify the CFG other >>>> passes like dominance information are still valid, and we do not have to >>>> create a lot of auxiliary bbs, to be able to detect all regions. This >>>> saves memory and runtime. In general it is probably not too easy to

hi all, 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 it can be optimized > separately. > I think this is the best way to add region analysis. I must admit > this approach > helps me on another,

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

Hi folks, A few months back I finished writing and testing a pass which implements "structural analysis" as described originally by Sharir in 1980 ("Structural analysis: A new approach to flow analysis in optimizing compilers") and more recently by Muchnick in Advanced Compiler Design and Implementation. It analyses the CFG and recognises specific region schema, such as

Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain situations. Should repetitive basic blocks be removed? I have an example to show the problem. Following is the source code and the CFG is enclosed. int main() { int

On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all > exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain > situations. Should repetitive basic blocks be removed? Users

Hi, in lib/Analysis/RegionPass.cpp there are 3 occurrences of: CurrentRegion->getNameStr() These are slowing down compile times with polly. I would suggest to either remove these calls, or only turn on when the programmer asks for -debug. The reason for the slow pretty printing of types is the same as previously discussed in: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063755.html

On 01/27/2011 12:48 AM, Vu Le wrote: > 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

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

On 08/28/2013 10:08 AM, Sebastian Pop wrote: > Hi,tic > > in lib/Analysis/RegionPass.cpp there are 3 occurrences of: > CurrentRegion->getNameStr() > These are slowing down compile times with polly. > I would suggest to either remove these calls, > or only turn on when the programmer asks for -debug. > > The reason for the slow pretty printing of types is the same as

Greetings, We present “Machine Function Splitter”, a codegen optimization pass which splits functions into hot and cold parts. This pass leverages the basic block sections feature recently introduced in LLVM from the Propeller project. The pass targets functions with profile coverage, identifies cold blocks and moves them to a separate section. The linker groups all cold blocks across functions

Antony Blakey wrote: > SVN head LLVM and Clang built out of the box for me a week ago on > MSYS/MINGW, using the following files: Ok, I tried to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build

Oh, yes. My algorithm extracts regions in a top-down manner. I modified your RegionPass so that it only visits 2nd level regions. Those regions are extracted into functions and the process continues for the new functions. It's kind of messy since I've just played with LLVM. I'll modify the algorithm so it can extract regions bottom-up. Vu On Wed, Jan 26, 2011 at 10:10 PM, Tobias