search for: getexitingblocks

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,

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 Printing analysis 'Detect single entry single exit regions' for function 'njDecodeSOF': Region tree: [0] entry => <Function Return>   [1] entry => return     [2] if.end => return

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

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

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

Hi, I cannot find the getSmallConstantTripCount function in the current LLVM. Can anyone tell me whether there is still such a function to get the trip count in LLVM? Thank you very much. Best, Han

Hello, I have a question about exit blocks : is it true that every loop's exit block will contain only those comparisons that will lead to exit or to continue execution in loop? I have tried many examples , after optimizations it seems to be true, but does it have to be so? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi all, I got a question on loop exit condition identification based on LLVM. I made an assumption first that loop exit conditions are located in exiting basic blocks. Then I use loop->getExitingBlocks() to get all BBs. However, this policy seemed not work for combinational exit conditions, e.g. compounding conditions consists of conditions with logical predicates. *The problem is that LLVM discompose these compounding conditions and only returns the last conditions*. Obviously, it is not I...

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Wednesday, July 15, 2015 7:34:54 PM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung

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

Hello . I'm trying to implement FunctionPass for detecting loops in llvm IR. How can I get <condition> for loop from llvm::Loop object.? Is there any example? Thanks in advance, Edvard  -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120723/85e7f2f9/attachment.html>

Yes, that’s right. Some LLVM terminology though: The blocks you mention, are called the “exiting blocks” of the loop, and the blocks outside the loop (that are the targets of these exiting blocks) are called the exit blocks. getExitingBlocks in LoopInfoImpl.h is the code you’re interested in. By definition: one of the successor’s of the exiting block is an exit block, and it should have another successor that’s a block within the loop (since we know that an exiting block is *inside* a loop). Anna > On Jul 30, 2017, at 11:47 AM,...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Andreas Neustifter wrote: > Daniel Dunbar wrote: >> Thanks, applied as r78247. Next? :) > > Oh my, first he is lagging and now it's all a hurry :-) > > Okay, here comes the next one. > > I'm taking a short vacation next week so I will try to prepare 1 or 2 of > the next patches so that you can work on them

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:06:03 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration

...patch / refactoring the existing code. > Yes, sounds good. I will try to split it up myself first and ask when there are decisions to be made I'm not sure about. Ok! >>> +  /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). >>> +  /// (Modelled after getExitingBlocks().) >>> +  typedef std::pair<BlockT*,BlockT*> Edge; >>> +  void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { >>> +    // Sort the blocks vector so that we can use binary search to do quick >>> +    // lookups. >>> +    SmallVect...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Dunbar wrote: > Thanks, applied as r78247. Next? :) Oh my, first he is lagging and now it's all a hurry :-) Okay, here comes the next one. I'm taking a short vacation next week so I will try to prepare 1 or 2 of the next patches so that you can work on them as you have time. Greetings, Andi - --

...get...() functions should be marked 'const' when possible. Finally, I have some other technical comments inline with the diff below. Thanks again for sharing your work! - Daniel > + /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). > + /// (Modelled after getExitingBlocks().) > + typedef std::pair<BlockT*,BlockT*> Edge; > + void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { > + // Sort the blocks vector so that we can use binary search to do quick > + // lookups. > + SmallVector<BlockT*, 128> LoopBBs(block_beg...

Hi all, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-February/020396.html I implemented the algorithm presented in [Ball94]. It only instruments the minimal number of edges necessary for edge profiling. The main changes introduced by this patch are: *) a interface compatible rewrite of ProfileInfo *) a cleanup of ProfileInfoLoader (some functionality in ProfileInfoLoader

...mber of "nitpicks" mostly related to LLVM style: Well, they were to be expected :-) One never gets those right the first time contributing to a new project... > [...] >> + /// getExitEdges - Return all pairs of (_inside_block_,_outside_block_). >> + /// (Modelled after getExitingBlocks().) >> + typedef std::pair<BlockT*,BlockT*> Edge; >> + void getExitEdges(SmallVectorImpl<Edge> &ExitEdges) const { >> + // Sort the blocks vector so that we can use binary search to do quick >> + // lookups. >> + SmallVector<BlockT*, 128&g...

Hi all, I would like to propose an improvement of the “almost dead” block elimination in Transforms/Local.cpp so that it will preserve the canonical loop form for loops with a volatile iteration variable. *** Problem statement Nested loops in LCALS Subset B (https://codesign.llnl.gov/LCALS.php) are not vectorized with LLVM -O3 because the LLVM loop vectorizer fails the test whether the loop