[LLVMdev] [RFC] Defining Infinite Loops

[Daniel Berlin]

On Wed, Jul 15, 2015 at 11:00 PM, Chandler Carruth <chandlerc at google.com> wrote:
> FWIW, I'm very much in favor of having a firm and clear answer to these
> questions.
>
> I also agree that it is an absolute requirement that LLVM have *some*
> mechanism for supporting both languages with defined behavior for infinite
> loops and a language requirement that all loops terminate.
>
> However, I'd like to float an alternative approach. I've not spent a lot of
> time thinking about it, so I'm not sure its actually better. I'm wondering
> if you've already thought about it.
>
> What if we have an @llvm.noop.sideeffect() or some such which doesn't read
> or write memory in any way, but which a frontend can place inside a loop
> body to mark that its execution (perhaps infinitely) is in-and-of-itself a
> side effect of the program. We could then teach loop unrolling or the few
> other things that would care to collapse multiple ones into a single one,
> and not count them towards anything.

So, GCC tried this, and it was a bit awkward.
(The intrinsic was called builtin_maybe_infinite_loop).
It was so awkward it never made it into a release

This in part because it had to be duplicated properly in a lot of
places to preserve the semantic, and it meant, for example, you
couldn't just do CFG updates without also sometimes having to copy
this intrinsic

(I supposed the counter argument is you could just not touch the CFG,
but even things like critical edge splitting might require moving
them, IIRC)

On the other hand, without loop metadata that is guaranteed kept up to
date (and attached to non-natural loops as well), i don't know that
you have a better option.