search for: exitblocks

Hello all, I’m pretty new to LLVM. I'm writing a pass for loop optimization. I clone and rearrange loops, setting the cloned loop as the original loop’s parent. This can be done multiple times, until there is no more work to do. The trouble is, after the first time I do this, the cloned loop's SCEVs become unknown types when they should be AddRecExpr. If I re-run the whole pass on the

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

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

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

Hi, I have problems to estimate the loop exit count of a simple loop with the ScalarEvolution class. simple loop: ...... int a = 0; for(int i; i < 10; ++i){ a = a + 1; }; ...... For the loop analyzation I use the ScalarEvolution class with the following initialization: ...... void analysis(Function* func) DominatorTree DT = DominatorTree(); DT.recalculate(*func);

...cks, 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, generating unique sets is a pain because values are not > numbered and iteration order needs to be reproducible. We would need to keep > a SmallPtrSet for membership checking while populating the result vector. What about use the SetVector[1] as container? As its c...

...thm> #include <set> @@ -45,7 +46,7 @@ namespace { class CodeExtractor { typedef std::vector<Value*> Values; - std::set<BasicBlock*> BlocksToExtract; + SetVector<BasicBlock*> BlocksToExtract; DominatorTree* DT; bool AggregateArgs; unsigned NumExitBlocks; @@ -135,7 +136,7 @@ // We only want to code extract the second block now, and it becomes the new // header of the region. BasicBlock *OldPred = Header; - BlocksToExtract.erase(OldPred); + BlocksToExtract.remove(OldPred); BlocksToExtract.insert(NewBB); Header = NewBB; @@ -180,7 +...

I am reading the code for exit block transformation in loop simplify. I do not fully understand how exit blocks with out-of-loop dominators are transformed. In SplitLandingPadPredecessors, all the in-the-loop predecessors of the exits block are grouped and given to the .loopexit basic block and the out-of-loop predecessors are grouped and given to the .nonloopexit basic block. the .loopexit

...alue::use_iterator UI = I->use_begin(), E = I->use_end(); UI != E; ++UI) if (!definedInRegion(*UI)) { - outputs.push_back(I); + outputs.insert(I); break; } } // for: insts @@ -%ld,%ld +%ld,%ld @@ } // for: basic blocks NumExitBlocks = ExitBlocks.size(); - - // Eliminate duplicates. - std::sort(inputs.begin(), inputs.end()); - inputs.erase(std::unique(inputs.begin(), inputs.end()), inputs.end()); - std::sort(outputs.begin(), outputs.end()); - outputs.erase(std::unique(outputs.begin(), outputs.end()), outputs.end()); }...

On Jan 8, 2010, at 5:01 PM, Julien Lerouge wrote: > Hello, > > The CodeExtractor contains a std::set<BasicBlock*> to keep track of > the > blocks to extract. Iterators on this set are not deterministic, and so > the functions that are generated are not (the order of the > inputs/outputs can change). > > The attached patch uses a SetVector instead. Ok to apply ?

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

Tom, I think it might be productive to fork this thread to discuss making the requirements for upstreaming a new LLVM target more explicit and open. I'd also like to gauge interest in an idea I've discussed privately with a few community members, namely the concept of having a semi-official "incubation" system whereby proposed backends could get a trial run before becoming part