search for: staszak

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

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

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

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

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

...rate FALSE value. I know that this comment might be a little bit misleading. Probably the best idea is to delete it. > doesn't do what the comment says it does; the store into *Val is done when !LoopExitBB, not when LoopExitBB == LoopExitBB2. > > On Aug 6, 2010, at 12:54 AMPDT, Jakub Staszak wrote: > >> Hello again :) >> >> It's been some time since I sent you last patch, but here I'm again. I send the patch for PR5373. >> >> Regards >> -- >> Jakub Staszak > <pr5373.patch> >> >> _____________________________...

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: 3229 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090821/0e07e86f/attachment.obj>

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

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

Hello again :) It's been some time since I sent you last patch, but here I'm again. I send the patch for PR5373. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr5373.patch Type: application/octet-stream Size: 5913 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100806/75f6e44a/attachment.obj>

...: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 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> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs....

...On Nov 30, 2009, at 7:52 PM, Dan Gohman wrote: > 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 one, which was wrong. >> >> -Jakub >> >> On Nov 24, 2009...

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 one, which was wrong. > > -Jakub > > On Nov 24, 2009, at 2:28 PM, Dan Gohman wrote: > >> Hell...

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>

...se if (Val) { + // if LoopExitBB == LoopExitBB2 pick the first one (true). + *Val = ConstantInt::getFalse(Context); doesn't do what the comment says it does; the store into *Val is done when !LoopExitBB, not when LoopExitBB == LoopExitBB2. On Aug 6, 2010, at 12:54 AMPDT, Jakub Staszak wrote: > Hello again :) > > It's been some time since I sent you last patch, but here I'm again. > I send the patch for PR5373. > > Regards > -- > Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr5373.patch Type:...

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

Hello, This (quite big :-)) patch fixes PR3913. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr3913.patch Type: application/octet-stream Size: 1451 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090824/e9d36629/attachment.obj>

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>

On Oct 10, 2009, at 7:48 AM, Jakub Staszak wrote: > Hello, > > I'm back :) Great! > This patch fixes pr3707. Can you explain a little more what this does? What is the intuition behind disabling this optimization? -Chris

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>