search for: exitbb

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:

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

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,

Hi, Because of this "return true" not every block was visited and only one ExitBB was found (instead of two). Thus, loop was optimized as a trivial one, which was wrong. -Jakub On Nov 24, 2009, at 2:28 PM, Dan Gohman wrote: > Hello, > > I haven't studied this in detail, but at a first look this makes the > code inconsistent with the associated comments. Wh...

Hello, Yeah, sorry, you are right. My new idea is that only one ExitBB is found because Header ("for.body") is already marked as visited. I'm pretty sure that someone had a good reason to do this that way, but I can't find it out :) Dan, can you look at this patch? Thanks -Jakub -------------- next part -------------- A non-text attachment w...

...t "return true" causes the code to search blocks outside of loops for side effects. That's not what the code is supposed to do. Dan On Nov 27, 2009, at 3:01 AM, Jakub Staszak wrote: > Hi, > > Because of this "return true" not every block was visited and only one ExitBB was found (instead of two). Thus, loop was optimized as a trivial one, which was wrong. > > -Jakub > > On Nov 24, 2009, at 2:28 PM, Dan Gohman wrote: > >> Hello, >> >> I haven't studied this in detail, but at a first look this makes the code inconsistent wit...

Hello, This patch fixes pr5373, testcase of course attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: 5373.patch Type: application/octet-stream Size: 1540 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091123/3f8fe7b3/attachment.obj>

Hello, I haven't studied this in detail, but at a first look this makes the code inconsistent with the associated comments. Why should the code continue recursing past a loop exit? Dan On Nov 23, 2009, at 4:43 AM, Jakub Staszak <kuba at gcc.gnu.org> wrote: > Hello, > > This patch fixes pr5373, testcase of course attached. > > -Jakub > <5373.patch> >