search for: alwaysreturn

...runtime to determine the loop iteration > count will eventually cause the loop to terminate, but I don't see any > way to indicate to the optimizer that this is the case. > > Andrew I'm thinking a good way to support this feature would be to add a new function attribute "AlwaysReturn" that would indicate that a function does not contain any infinite loops, so that the LoopDeletion pass and others could treat it accordingly. What do you think? What's the best way for me to submit changes back to the LLVM repository? Andrew

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>(); >>

...p iteration >> count will eventually cause the loop to terminate, but I don't see any >> way to indicate to the optimizer that this is the case. >> >> Andrew > > I'm thinking a good way to support this feature would be to add a new > function attribute "AlwaysReturn" that would indicate that a function > does not contain any infinite loops, so that the LoopDeletion pass and > others could treat it accordingly. What do you think? I called it "halting": http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html bu...

On Fri, Jul 15, 2016 at 2:44 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Daniel, > > Daniel Berlin wrote: > > Don't we have the same problems for "exit(0)" > > > > > > This is a noreturn call, so yes, iit has another hidden control > > flow-side-effect of a slightly different kind. GCC models it as an extra >