[PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713)
Marc Glisse
marc.glisse@inria.fr
Tue May 21 08:06:00 GMT 2019
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
More information about the Gcc-patches
mailing list