Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)

[Marc Glisse <marc.glisse@inria.fr>]

On Mon, 20 May 2019, Michael Matz wrote:

> On Mon, 20 May 2019, Richard Biener wrote:
>
>>> The C++ standard says that do{}while(1) is __builtin_unreachable(), we
>>> don't have to preserve it. There is no mention of anything like a
>>> "nontrivial exit condition". Other languages may have a different
>>> opinion though, so it would probably need a flag indeed... But I am
>>> curious what the point of such a loop is.
>>
>> busy wait until wakeup by signal or interrupt.
>
> I'd actually turn it around from what C++ says.  If the user wrote, as
> is, "do{}while(1);" or "while(1);" or "for(;;);" then we can assume
> something funky going on and not remove the loop.  For any other loop we
> assume that they are finite.  I.e. we mark loops as to-be-preserved (which
> we set on a few known patterns), and just remove all other loops when they
> contain no observable side effects after optimization.

Seems sensible, although marking the trivial infinite loops in gimple 
seems simpler than doing it in the front-ends, and a good enough 
approximation unless we are willing to replace some other infinite loops 
with unreachable (or trap).

> And of course we'd still have to determine what acceptable side effects
> are.  E.g. in a pointer chasing loop containing no body, is the
> segfault when the pointer chain is not in fact circular, a side effect we
> should retain, or should we be allowed to remove the loop?  I'd say we
> should remove the loop, of course.

That may depend on flags like -fnon-call-exceptions (maybe not the right 
one) I guess, although I would also want the removal to happen in as many 
cases as possible. We do usually remove memory reads if the value read is 
unused.

> (And yes, I've always found our obsession with preserving infinite loops,
> outside of the above "obvious" cases, overly anal as well)

-- 
Marc Glisse