search for: getexitblock

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

Hi, LoopBase::getExitBlocks in LoopInfo.h returns all exit basic blocks by iterating over all blocks of a loop and storing all branch targets that are outside the loop. This method allows for duplicates in the result vector, e.g.: Loop at depth 2 containing: %bb2<header><exit>,%bb1<latch>,%bb3<exit>...

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 generally expect a unique set of exit blocks...

On Apr 23, 2012, at 10:31 PM, Andrew Trick <atrick at apple.com> wrote: > > 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 generally expect a unique...

hi, > Users generally expect a unique set of exit blocks, but don't make any > strong assumption. The worst that can happen is missed optimization or > redundant analysis. In most cases, the loop is in LoopSimplifyForm, so it's > probably not a problem in practice. > > > Another thing I should mention. The iteration order of ExitBlocks is > important. In llvm,

...opPreheader(); // keep track of the original predecessors std::set<BasicBlock *> AllPredecessors; for (auto PredIt = pred_begin(PreHeader), E = pred_end(PreHeader); PredIt != E; PredIt++) AllPredecessors.insert(*PredIt); BasicBlock *ExitBlock = L->getExitBlock(); auto DT = DominatorTree(*F); SmallVector<BasicBlock *, 8> Blocks; const auto ClonedLoop = cloneLoopWithPreheader(PreHeader, PreHeader, L, VMap, NameSuffix, LI, &DT, Blocks); VMap[ExitBlock] = PreHeader; // chain: cloned loop -> original loop remapInstru...

...loop and a region 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

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

...orrect. > 3. 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. H...

...orrect. > 3. 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. H...

...do quick >>> +    // lookups. >>> +    SmallVector<BlockT*, 128> LoopBBs(block_begin(), block_end()); >>> +    std::sort(LoopBBs.begin(), LoopBBs.end()); >> >> Would it be better to use a DenseSet for this lookup? > Well, its the same that is used in getExitBlocks() where I got the implementation from. I really don't know but I think the current implementation is okay from what I gather form the LLVM Programmer's Manual. There is nothing wrong with it, but using a DenseSet has better asymptotic performance and shortens the code. OTOH it may have a...

...can use binary search to do quick >> + // lookups. >> + SmallVector<BlockT*, 128> LoopBBs(block_begin(), block_end()); >> + std::sort(LoopBBs.begin(), LoopBBs.end()); > > Would it be better to use a DenseSet for this lookup? Well, its the same that is used in getExitBlocks() where I got the implementation from. I really don't know but I think the current implementation is okay from what I gather form the LLVM Programmer's Manual. >> --- llvm-van/include/llvm/Analysis/MaximumSpanningTree.h 1970-01-01 01:00:00.000000000 +0100 >> +++ llvm-c7/i...

Hi, It's been a while since I sent the last compile time report [1], where it was shown that LLVM was getting slower over time. But now I'm happy to bring some good news: finally, LLVM is getting faster, not slower :) *** Current status *** Many areas of LLVM have been examined and improved since then: InstCombine, SCEV, APInt implementation, and that resulted in almost 10% improvement

Hi Andreas, First, thanks again for undertaking this work and submitting it back. There is a lot of good stuff here and it would be great to see it get back into the tree. I have a few major high-level comments on the patch. First off, the patch is quite large and should be broken down into separate incremental changes which are easier to review and apply. I think the patches should more or less

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