search for: getexitingblock

...ion could have parent or childrens 3. both of them have a BasicBlocks(header of a loop and "entry" of a region) that dominates all others and the Region class will have the most stuffs very similar in LoopBase, like: ParentRegion, SubRegions, Blocks, getRegionDepth(), getExitBlock(), getExitingBlock() ...... so, could us just treat "Loop" as some kind of general "Region" of BasicBlocks, and make Loop and Region inherit from "RegionBase"? [1] http://llvm.org/doxygen/LoopInfo_8h-source.html best regards --ether

...4  libc.so.6       0x00007fe7ed17dfc6 abort + 390 5  libc.so.6       0x00007fe7ed1758ce 6  libc.so.6       0x00007fe7ed175990 __assert_perror_fail + 0 7  opt             0x0000000000921a70 llvm::Region::contains(llvm::BasicBlock const*) const + 96 8  opt             0x0000000000921f2e llvm::Region::getExitingBlock() const + 142 9  opt             0x0000000000921fd9 llvm::Region::isSimple() const + 73 10 opt             0x00000000009244dc llvm::RegionInfo::updateStatistics(llvm::Region*) + 44 11 opt             0x0000000000924657 llvm::RegionInfo::createRegion(llvm::BasicBlock*, llvm::BasicBlock*) + 327 12 op...

...childrens > 3. both of them have a BasicBlocks(header of a loop and "entry" of a > region) that dominates all others > > and the Region class will have the most stuffs very similar in LoopBase, > like: ParentRegion, SubRegions, Blocks, getRegionDepth(), > getExitBlock(), getExitingBlock() ...... > > so, could us just treat "Loop" as some kind of general "Region" of > BasicBlocks, and make Loop and Region inherit from "RegionBase"? > > > [1] http://llvm.org/doxygen/LoopInfo_8h-source.html > > best regards > --ether

...7fe7ed17dfc6 abort + 390 > 5 libc.so.6 0x00007fe7ed1758ce > 6 libc.so.6 0x00007fe7ed175990 __assert_perror_fail + 0 > 7 opt 0x0000000000921a70 > llvm::Region::contains(llvm::BasicBlock const*) const + 96 > 8 opt 0x0000000000921f2e llvm::Region::getExitingBlock() > const + 142 > 9 opt 0x0000000000921fd9 llvm::Region::isSimple() const + 73 > 10 opt 0x00000000009244dc > llvm::RegionInfo::updateStatistics(llvm::Region*) + 44 > 11 opt 0x0000000000924657 > llvm::RegionInfo::createRegion(llvm::BasicBlock*,...

...both of them have a BasicBlocks(header of a loop and "entry" of a > region) that dominates all others Correct. > and the Region class will have the most stuffs very similar in LoopBase, > like: ParentRegion, SubRegions, Blocks, getRegionDepth(), Correct. > getExitBlock(), getExitingBlock() ...... This might need some thoughts, > so, could us just treat "Loop" as some kind of general "Region" of > BasicBlocks, and make Loop and Region inherit from "RegionBase"? I would like to do so, as I like the structure of this approach. However until now my...

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

...block is %for.body). The check in the vectorizer is explicit: // We only handle bottom-tested loops, i.e. loop in which the condition is // checked at the end of each iteration. With that we can assume that all // instructions in the loop are executed the same number of times. if (TheLoop->getExitingBlock() != TheLoop->getLoopLatch()) { ... -Hal > That seems both counter-intuitive and unlikely to be a useful goal. > We simply don't optimize volatile operations well in *any* part of > the optimizer, and I'm not sure why we need to start trying to fix > that. This seems lik...

...both of them have a BasicBlocks(header of a loop and "entry" of a > region) that dominates all others Correct. > and the Region class will have the most stuffs very similar in LoopBase, > like: ParentRegion, SubRegions, Blocks, getRegionDepth(), Correct. > getExitBlock(), getExitingBlock() ...... This might need some thoughts, > so, could us just treat "Loop" as some kind of general "Region" of > BasicBlocks, and make Loop and Region inherit from "RegionBase"? I would like to do so, as I like the structure of this approach. However until now my...

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

...handle bottom-tested loops, i.e. loop in which the > > condition is > > > // checked at the end of each iteration. With that we can assume > > that > > all > > > // instructions in the loop are executed the same number of times. > > > if (TheLoop->getExitingBlock() != TheLoop->getLoopLatch()) { > > > ... > > Thanks for the detailed explanation. This makes much more sense why > we need to handle it. I think its much better to look at nested > loops of this form than anything to do with volatile -- the latter > is too prone to ot...

...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. >>> +    SmallVec...

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

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

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