similar to: [LLVMdev] Is MachineLoop Simplify Form?

Antony Blakey wrote: > SVN head LLVM and Clang built out of the box for me a week ago on > MSYS/MINGW, using the following files: Ok, I tried to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build

Thanks, Also, every method inherited by LoopBase causes the same error, while Loop methods go smooth. On 9 May 2013 01:05, Andrew Trick <atrick at apple.com> wrote: > > On May 8, 2013, at 7:43 PM, Giacomo Tagliabue <giacomo.tag at gmail.com> > wrote: > > Hello, > I am building a loop pass following these instructions: >

Wow, commenting those two lines worked out fine for me, thanks! On 9 May 2013 09:34, Giacomo Tagliabue <giacomo.tag at gmail.com> wrote: > Thanks, > Also, every method inherited by LoopBase causes the same error, while Loop > methods go smooth. > > > On 9 May 2013 01:05, Andrew Trick <atrick at apple.com> wrote: > >> >> On May 8, 2013, at 7:43 PM,

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 May 8, 2013, at 7:43 PM, Giacomo Tagliabue <giacomo.tag at gmail.com> wrote: > Hello, > I am building a loop pass following these instructions: http://llvm.org/docs/WritingAnLLVMPass.html > Everything works fine, I did it many times for Function Passes, but in the runOnLoopmethod, whenever I call a method of the loop L passed as argument, for example L->begin(), I get the

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 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'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 code and the CFG is enclosed. int main() { int

Hi, I was reading some loop related code and I don’t quite understand an assertion in LoopBase<BlockT, LoopT>::getLoopPredecessor(). /// getLoopPredecessor - If the given loop's header has exactly one unique /// predecessor outside the loop, return it. Otherwise return null. /// This is less strict that the loop "preheader" concept, which requires /// the predecessor to have

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

Hi all, I have a question about llvm::LoopBase getBlocks() method. Does it return the basic blocks inside the loop in random order? I need to order the blocks in some valid topological ordering of the AST. If getBlocks() does not do that, what can I do to find the ordering? Thanks, Naznin -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am trying to build 3.2 and get this error: make[2]: Leaving directory `/home/opt/llvm-3.2.src/unittests/ADT' /home/opt/llvm-3.2.src/unittests/Analysis/Release+Asserts/ScalarEvolutionTest.o: In function `llvm::(anonymous namespace)::ScalarEvolutionsTest_SCEVMultiplyAddRecs_Test::TestBody()': ScalarEvolutionTest.cpp:(.text+0x1408): undefined reference to

Hi, I am writing a loop pass to replace the backedge with an edge from latch to exit. Now I just replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void llvm::LoopBase<N, M>::verifyLoop() const [with

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall

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

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> where both bb2 and bb3 have bb4 as their exit block. This loop

Whenever I was tying to do that (in version 2.8), it didn't give them to me in a topological order. What I did, as a hack-ish temporary measure, was rely on Function's ordering, and just iterated over all the blocks in the function, checking to see if the loop contains that block. Not at all ideal, and what I was writing later evolved to not need the topological ordering constraint, so I

On May 7, 2013, at 8:26 PM, zhiyuan yang <sjtu.yzy at gmail.com> wrote: > Hi, > > I am writing a loop pass to replace the backedge with an edge from latch to exit. > Now I just replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: > > opt:

Thanks Michael. Can you please explain you way a bit more? Did you run a function pass then a loop pass? On Mon, May 9, 2011 at 12:56 PM, Michael Ilseman <michael at lunarg.com> wrote: > Whenever I was tying to do that (in version 2.8), it didn't give them > to me in a topological order. What I did, as a hack-ish temporary > measure, was rely on Function's ordering, and

Sorry for forgetting to reply all... It works! Thank you very much! But I also wonder how do you know this function will work while there are no documents noticing that. I try learning LLVM by reading its code, but soon feel lost in so many functions. Just like I have many tools, but don't know which to use and what difference it could make. Is there some better ways to learn LLVM? On Wed,