[Bug tree-optimization/57723] Missed optimization: recursion around empty function

[petschy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723

--- Comment #10 from petschy at gmail dot com ---
Thanks for the explanation. The multithreaded argument is sound, but then, on
second thought, even in single threaded programs the state might be altered by
a signal handler, or another process if the memory is shared, so the
optimization might break the program. The bottom line is that the compiler
doesn't have enough information, so it must be conservative, hence the loop
stays in.

Adding a new fn attribute probably wouldn't be enough, since in general there
might be more than one potentially infinite loop inside the fn, with different
semantics, so optimizing all of them away still could be improper. Hence the
attribute should apply to a given loop only ('finite'), but implementing it is
probably too much trouble for this rare case, and the compiler still needs to
eliminate the recursion, too, which might be more complex, eg multiple
functions calling each other in the general case.

For my specific case, I can solve the problem by providing a trait for the
allocator which says 'free() is NOP, so don't bother', then the top level
function can decide what to do, traverse & free or do nothing.

Mikael: could you please provide some info on the ptrace() wizardy you
mentioned, if it's not confidental? I got curious.

Based on the discussion so far, do you think that clang is overly smart in this
case, producing potentially broken code? free_all2() was compiled into a single
ret, and the other two functions lack the recursion, only have the node
traversal of the current level, which seems to be an error to me, because if
there is an infinite loop on one of the levels, the program's behaviour will be
different when compiled with optimizations. If I set n_->down to null before
the recursive call, it generated the expected code, which is interesting, since
then the loop is more likely on the 'finite side'.

Thanks, Peter