(@Feng Xue, it is better to include testcases in your patches)
I'm not a big fan of this patch. I'd rather be looking at either
improving our analysis
Better analysis cannot hurt.
or adding attributes to the loops to help the analysis bits prove
termination.
There may not be a loop in the source code, it may be a recursive function
call that gcc turned into a loop. Plus, I know that it applies to all
loops in my program.
We could have a function to compute the length of a linked list:
struct A { A*p; };
unsigned l(A*a){return a?l(a->p)+1:0;}
and because of other optimizations, it turns out that we do not actually
use this length
void g(A*a){l(a);}
wouldn't it be nice if gcc could remove all that useless code, instead of
keeping a useless loop on the off chance that it might be infinite?
And we had sth similar in the past and ended up removing it.
-funsafe-loop-optimizations IIRC.
IIUC that was slightly different: "This option tells the loop optimizer to
assume that loop indices do not overflow, and that loops with nontrivial
exit condition are not infinite."
The assumption on indices looks unsafe indeed if it applied to unsigned
indices in non-empty loops.
But the C++ standard went to the trouble of banning infinite loops without
side effects specifically to enable DCE on this type of code... Actually,
an infinite loop with a trivial exit condition looks like a great
opportunity to use __builtin_unreachable() to me ;-) (I have been wanting
a -fmain-does-return -fno-funny-business for years, since I looked at
replacing some malloc with stack allocations, but that's all out of scope
for this patch)
Why exactly are we trying so hard to preserve no-side-effect, infinite
loops? What are they good for? Note that reading an atomic or volatile
variable counts as a side effect for this purpose. It looks like some kind
of busy waiting, but without checking a flag, so it can only be stopped by
some external action (say a signal), so if the OS has any notion of sleep
for a thread, blocking would be better. Or maybe it is running through a
circular list, ensuring that it stays in RAM? Anyway it seems specific
enough that that strange code should be the one needing an annotation.
--
Marc Glisse
