similar to: [LLVMdev] Adding a halting function attribute?

On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > Hey folks, > > In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem is that isTriviallyDeletable currently returns true for any read-only function

On May 1, 2010, at 11:19 AM, Chris Lattner wrote: > > On May 1, 2010, at 11:07 AM, Owen Anderson wrote: > >> Hey folks, >> >> In a recent blog post, John Regehr pointed out that LLVM is currently optimizing away read-only functions containing infinite loops whose return values are never used. The culprit for the moment is the inliner, but the more insidious problem

On 11/25/2010 12:59 PM, Andrew Clinton wrote: > On 11/24/2010 06:55 PM, Owen Anderson wrote: >> On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: >> >> >>> Most of my programs contain loops that the LoopDeletion pass is unable >>> to remove. It appears that the following code in LoopDeletion.cpp:152 >>> is the culprit: >>> >>>

On 11/24/2010 06:55 PM, Owen Anderson wrote: > On Nov 23, 2010, at 9:22 AM, Andrew Clinton wrote: > > >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >>

On Sun, May 2, 2010 at 9:32 AM, John Regehr <regehr at cs.utah.edu> wrote: > > On reflection, perhaps this isn't so bad. This really only matters when > > the compiler is able to infer readnone/readonly, which typically doesn't > > include cases with indirect calls. Per #2, I think it could be handled > > by making the GCC-style pure/const attributes imply

Hi All, We’ve prepared a new function attribute `maynotprogress` and loop metadata `llvm.loop.mustprogress` in order to better formalize the way LLVM deals with infinite loops without observable side-effects. This is deeply related to the implicit forward progress requirements in the IR. Background: There has been a demonstrated need for clarity within the forward progress requirements in LLVM

> On reflection, perhaps this isn't so bad. This really only matters when > the compiler is able to infer readnone/readonly, which typically doesn't > include cases with indirect calls. Per #2, I think it could be handled > by making the GCC-style pure/const attributes imply both > readonly/readnone *and* halting. This sounds right to me. John

> You dropped some context... > A daemon program wouldn't be readonly. An infinite loop can be. Right. To prevent miscommunication, here is a quick analysis of a problematic (IMO) example: We start with ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret

On 11/24/2010 03:36 PM, Nick Lewycky wrote: > Andrew Clinton wrote: >> Most of my programs contain loops that the LoopDeletion pass is unable >> to remove. It appears that the following code in LoopDeletion.cpp:152 >> is the culprit: >> >> ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); >> const SCEV *S =

On 9/4/20 7:39 PM, Hal Finkel via llvm-dev wrote: > > On 9/4/20 6:31 PM, Atmn Patel via llvm-dev wrote: >> Hi All, >> >> We’ve prepared a new function attribute `maynotprogress` and loop >> metadata `llvm.loop.mustprogress` in order to better formalize the way >> LLVM deals with infinite loops without observable side-effects. This >> is deeply

On Nov 24, 2010, at 1:23 PM, Andrew Clinton wrote: > > FYI, removing the ScalarEvolution conditional in the LoopDeletion code > (and copying the algorithm to my own loop deletion pass) seems to > correctly handle the elimination of infinite loops. However I'd still > like to find a way to do this with standard passes if possible. There is no way to do this with the

Don't say I didn't warn you: http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long Don't get me wrong, I'll be as ecstatic as any of you to see Theora and VP8 succeed, I just see the patent system as far more insidious than I think many of you do. Shayne

Hello! I am undertaking my first attempt at using compiled C code within R and have run into this lovely problem when I call my C code (using .C). The instruction at "0x10001d1b" referenced memory at "0x01fa2000". The memory could not be "written". Now this doesn't happen every time and furthermore I've tested the code in plain C and it all works

Most of my programs contain loops that the LoopDeletion pass is unable to remove. It appears that the following code in LoopDeletion.cpp:152 is the culprit: ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); const SCEV *S = SE.getMaxBackedgeTakenCount(L); if (isa<SCEVCouldNotCompute>(S)) return Changed; So, LoopDeletion thinks my loops might be infinite so it

I''m reasonably confident that the problem I''m having here is upstream. RHEL5: # yum repolist | grep puppet puppetlabs-deps Puppet Labs Dependencies El 5 - x86_64 45 puppetlabs-products Puppet Labs Products El 5 - x86_64 161 # yum clean all Loaded plugins: security Cleaning up Everything # yum repolist 2>&1 | grep puppet

Andrew Clinton wrote: > Most of my programs contain loops that the LoopDeletion pass is unable > to remove. It appears that the following code in LoopDeletion.cpp:152 > is the culprit: > > ScalarEvolution& SE = getAnalysis<ScalarEvolution>(); > const SCEV *S = SE.getMaxBackedgeTakenCount(L); > if (isa<SCEVCouldNotCompute>(S)) > return

Patenting a mathematical formula is NOT creating a machine nor is it unique. For example. 2+2=4... apples + apples^2= given outcome. I want to patent this. It's stupid to patent something like that. The same is true for formula algorithms. Algorithms occur in nature. Thus should not be patented. Now, Volley G Mathison inventor of the Electropsychometer had a machine that he could patent. A

On Nov 24, 2010, at 3:58 PM, Owen Anderson wrote: > > On Nov 24, 2010, at 1:23 PM, Andrew Clinton wrote: >> >> FYI, removing the ScalarEvolution conditional in the LoopDeletion code >> (and copying the algorithm to my own loop deletion pass) seems to >> correctly handle the elimination of infinite loops. However I'd still >> like to find a way to do

Hello All, I filed a bug https://bugs.llvm.org/show_bug.cgi?id=35884 which I want to fix but I'm in trouble with detecting who is wrong :) The story is as follows: LoopDeletion tries to delete an invariant loop which has a def with use in some unreachable block. The IR is well-formed due to any use in unreachable block is dominated as Verifier states. LoopDeletion detected the loop as

Hello! I read a bunch of discussions about the matter on this very mailing-list that are relatively recent or relatively old and I couldn’t find much agreement on the matter, so … here again :D LoopDeletion and infinite loops … Currently LoopDeletion bails if non-detectable trip count loops are encountered and that’s fine, there are languages where infinite loops without side effects cannot be