similar to: [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, >>>>

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

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

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

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

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

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, >> >> This patch fixes PR4174. Two test-cases included: original one from >> bugzilla >> and a little bit complicated made be myself. > > I think you want isSafeToSpeculativelyExecute rather than >

Hello again :) After some break I send patch for PR4174. It was proposed some time ago, this one works with trunk. Regards -- Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr4174-4.patch Type: application/octet-stream Size: 2932 bytes Desc: not available URL:

Hi, All CallInsts should return true for Instruction::mayHaveSideEffects() because functions are not guaranteed to halt. Inliner::runOnSCC calls isInstructionTriviallyDead to determine whether code can be dead code eliminated. isInstructionTriviallyDead returns true if Instruction::mayHaveSideEffects() returns false. A function that potentially runs forever based on its input but does not write

Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev]

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

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

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:

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>

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

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>

Hello, I was wondering about the case below. I tried to find any information in C standard, but I found nothing. In this case, variable "i" is uninitialized, but it is the _same_ value passed as an argument, so only of "a" or "b" should be printed. What I found is that with -O2: LLVM (trunk) prints both "a" and "b" GCC (4.2) prints both

Hello, Currently, llvm::isSafeToSpeculativelyExecute() always returns false for Call instructions. This has actual performance implications, because loop-invariant code motion makes this check, and will never hoist instructions that are not safe to speculatively execute. Unfortunately, there is currently no way to signal to LICM that a function is safe to speculatively execute. The

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