similar to: [LLVMdev] PR5373

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] PR5373"

2010 Aug 06
0
[LLVMdev] PR5373
The last bit here + if (LoopExitBB) { + // It is possible that for both successors isTrivialLoopExitBlock() + // returns different exit blocks. It means that the loop isn't trivial, + // just quit then. + if (LoopExitBB != LoopExitBB2) + return false; + } else if (Val) { + // if LoopExitBB == LoopExitBB2 pick the first one (true). +
2010 Aug 06
2
[LLVMdev] PR5373
On Aug 6, 2010, at 11:47 AM, Dale Johannesen wrote: > The last bit here > > + if (LoopExitBB) { > + // It is possible that for both successors isTrivialLoopExitBlock() > + // returns different exit blocks. It means that the loop isn't trivial, > + // just quit then. > + if (LoopExitBB != LoopExitBB2) > + return false; > +
2010 Aug 11
0
[LLVMdev] PR5373
Hello, Fixed patch attached. Can anyone test it? Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr5373.patch Type: application/octet-stream Size: 5846 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100811/8c0c364b/attachment.obj> -------------- next part -------------- On Aug 6, 2010, at
2009 Dec 06
1
[LLVMdev] PR5373
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 was scrubbed... Name:
2009 Nov 27
2
[LLVMdev] PR5373
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. Why
2009 Nov 23
3
[LLVMdev] PR5373
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>
2009 Nov 30
0
[LLVMdev] PR5373
Hello, Simply removing that "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
2009 Nov 24
0
[LLVMdev] PR5373
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> >
2013 May 13
3
[LLVMdev] Q: When is a boolean not a boolean?
A: When the types are created in different contexts. I've been running into a module validation error related to phi nodes produced by the GVN pass, where the types of the incoming values aren't the same instance of IntegerType i1. I'm not certain I've found the root cause of the problem yet, it's probably due to my handling of LLVMContext & Module life cycles, and this
2013 May 13
0
[LLVMdev] Q: When is a boolean not a boolean?
Jeremy Lakeman wrote: > A: When the types are created in different contexts. > > I've been running into a module validation error related to phi nodes > produced by the GVN pass, where the types of the incoming values aren't > the same instance of IntegerType i1. > > I'm not certain I've found the root cause of the problem yet, it's > probably due to my
2009 Aug 22
2
[LLVMdev] PR4174
On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 8:46 PM, Eli
2009 Aug 22
2
[LLVMdev] PR4174
On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> On Aug 21, 2009, at 7:31 PM, Eli
2009 Aug 21
3
[LLVMdev] PR4174
Hello, This patch fixes PR4174. Two test-cases included: original one from bugzilla and a little bit complicated made be myself. It seems that LoopIndexSplit doesn't handle some cases, I'll try to send some patch this week. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174.patch Type: application/octet-stream Size:
2009 Aug 21
1
[LLVMdev] PR4174
On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> > wrote: >> >> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >> >>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at gcc.gnu.org> >>> wrote: >>>> >>>> Hello, >>>>
2009 Aug 22
0
[LLVMdev] PR4174
On Fri, Aug 21, 2009 at 5:47 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:27 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at
2009 Aug 22
0
[LLVMdev] PR4174
On Fri, Aug 21, 2009 at 5:05 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 10:02 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at
2009 Aug 22
0
[LLVMdev] PR4174
On Fri, Aug 21, 2009 at 4:53 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: > > On Aug 21, 2009, at 8:46 PM, Eli Friedman wrote: > >> On Fri, Aug 21, 2009 at 3:29 PM, Jakub Staszak<kuba at gcc.gnu.org> wrote: >>> >>> On Aug 21, 2009, at 7:31 PM, Eli Friedman wrote: >>> >>>> On Fri, Aug 21, 2009 at 2:06 PM, Jakub Staszak<kuba at
2010 May 08
2
[LLVMdev] PR7052
Hello, This patch fixes PR7052. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr7052.patch Type: application/octet-stream Size: 3223 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100508/4648de5a/attachment.obj>
2009 Oct 10
2
[LLVMdev] PR3707
Hello, I'm back :) This patch fixes pr3707. Regards -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: pr3707.patch Type: application/octet-stream Size: 3247 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091010/301a2761/attachment.obj>
2009 Aug 06
1
[LLVMdev] [PATCH] PR4667
Hello, This patch fixes PR4667. Regards, Jakub Staszak P.S. ping: http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-July/024369.html -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4667.patch Type: application/octet-stream Size: 2148 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090806/27d1e11e/attachment.obj>