llvm dev - Sep 2017 - About LoopDeletion and infinite loops ... again! (RFC?)

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.

Thanks,
Marcello
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170929/4285285a/attachment.html>

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

I see the usecase for mixed language compilation (that’s probably why you fancy
something like the side-effect thing instead right?)

BTW if the other proposal passes can we basically assume that if a loop doesn’t
have the sideeffect intrinsic in it is then removable?

That patch seems to suggest that in its current state llvm is mostly broken for
languages that consider all infinite loops as unremovable ... (but I didn’t read
all the discussion)

Marcello

Sent from my iPhone
> On Sep 29, 2017, at 7:43 PM, Davide Italiano <davide at freebsd.org>
wrote:
> 
> 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