> I don't see how it is safe in a late pass when it is not safe in an
> earlier one. Optimization is imperfect - we could fail to remove
> an "obvious" never taken exit and still have a loop that appears to be
> finite according to our definition.
Yes. it is. This is somewhat similar to strict-alias option/loop dep pragma.
Compiler tries to do something based on hint you tell it, but does not ensure
correctness.
> The only way
> to define it would be if there was, at any point, an exit from the
> loop (and there it _may_ be exclude EH edges) then
> the loop is assumed to be finite.
No catch your point. If we treat an infinite loop as finite, it's bad because
the loop might be removed.
Suppose we have a function:
void foo(int bound)
{ for (int i = 0; i <= bound; i++); }
In an early CD-DCE pass, "bound" is represented as a variable, and loop has a
exit, so it is assumed to finite, and is removed.
But in a late pass, this function is inlined into another one, and "bound" has
value of INT_MAX, this loop is infinite, and here we can know it should not be
removed.
This is why I suggest doing the optimization as late as possible.
Feng
