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

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 >>

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/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 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

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/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/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,

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 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,

How is the patch compressed? I don't know how to open the file with .7z suffix. Evan On Feb 27, 2010, at 10:12 PM, ether zhhb wrote: > hi all, > > The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the

hi all, The patch in the attachment add a new pass - region pass to the llvm system. A region pass is similar to a loop pass, all of them execute on a group of BasicBlocks at one time, but it operate on a single entry single exit region, not the nature loop. The original purpose to add such a pass to llvm system is to allow us find out the static control part (SCoP) for the polyhedral

Hi all, I'm working with regions, and I was surprised by the region set of this function: > define void @foo() { > br i1 false, label %loop, label %end > > loop: > br i1 false, label %loop, label %end > > end: > ret void > } .dot file as generated by opt —view-regions attached. Essentially, there are 3 regions: one that has the whole function, one that has

That looks like something from 7-zip (http://www.7-zip.org/). Ether, can you re-send either as a plain-text attachment, or if you need to use an archive, .zip or .tar.gz so it's a bit more standard for those of us not working on a Windows platform? Thanks! -Jim On Mar 4, 2010, at 11:15 AM, Evan Cheng wrote: > How is the patch compressed? I don't know how to open the file with .7z

On 03/16/2010 05:02 PM, James Stanier wrote: > > Hi Trevor, > > I just studied your diagrams -- I *think* that the "control tree" of > structural analysis is not same as the "control flow tree" from your own > Java work. However, as you understand your work more than I do, I present > you with some fancy coloured diagrams that I drew that might help you

Hi, I want to write a pass that pulls single-entry a single-exit (SESE) region into a function. The idea is similar to extracting a loop in LoopExtractor.cpp. Basically, for each region that meet our criteria, 1. Find all basic blocks in that regions 2. Call llvm::ExtractCodeRegion() to replace that region by a call to the extracted function. 3. Delete the region from the RegionPassManager queue

>Exceptions >All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work. Can you elaborate more on the outstanding issues with splitting eh pads? From my dip into the unwind map in gcc_except_table the

Michael, [Sorry that I don't have you in To:. I don't have your addr that I can use since I'm replying through digest.] I'm also sorry that I'm not commenting on the main part of your RFC in this reply. I just want to focus on one thing here. Proposed Loop Optimization Framework ------------------------------------

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 Sjoerd, On 09/20, Sjoerd Meijer wrote: > I have not been following the polyhedral developments in both GCC and > LLVM very closely the last few years, but I was just wondering if > there are any lessons learned we should look at (or actually already > aware of) in GCC's implementation and integration of Graphite. For > example, do we know if it is (still) enabled/used/etc.?