[llvm-dev] About LoopDeletion and infinite loops ... again! (RFC?)

[Davide Italiano via llvm-dev]

On Fri, Sep 29, 2017 at 7:17 PM, Marcello Maggioni via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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 removed.
>
> If I read the C++ spec right though N4527 (sec 1.10)  point 27 says:
>
> 27  The implementation may assume that any thread will eventually do one of
> the following:
>
> 27.1 — terminate,
>
> 27.2 — make a call to a library I/O function
>
> (27.3)— read or modify a volatile object, or
>
> (27.4)— perform a synchronization operation or an atomic operation.
>
> [Note: This is intended to allow compiler transformations such as removal of
> empty loops, even when
>
> termination cannot be proven. — end note ]
>
>
> So, the spec seems to be explicitly calling out that removing infinite loops
> is ok unless they do any of the things mentioned there (at least that is my
> interpretation, is that correct?).
>
>
> If that is the case we could be missing out for languages that have such a
> behavior (and in particular in C++).
>
> I was wondering how it would be viewed the possibility of adding a flag to
> loop deletion that allows the removal of loops with loop counts that are not
> SCEVable.
>

You probably have seen it, but, for reference
https://reviews.llvm.org/D38336 (which goes in the exact opposite direction).

I don't necessarily fancy the idea of having a flag, instead, maybe,
the frontend could emit enough information to tell the optimizer
whether it is safe to remove the loop?

Thanks,

--
Davide