gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in the future...

* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
	the future; indeed that already happens in some cases.

From-SVN: r24442
This commit is contained in:
Gerald Pfeifer 1998-12-30 06:28:05 +01:00 committed by Gerald Pfeifer
parent 30dfe54ae2
commit c2a2650529
2 changed files with 16 additions and 5 deletions

View File

@ -1,3 +1,8 @@
Mon Dec 28 19:26:32 1998 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
the future; indeed that already happens in some cases.
Tue Dec 29 11:58:53 1998 Richard Henderson <rth@cygnus.com>
* sparc.c (input_operand): Recognize (const (constant_p_rtx)).

View File

@ -2005,12 +2005,18 @@ test explicitly for C++ as well.
@item
Deleting ``empty'' loops.
GNU CC does not delete ``empty'' loops because the most likely reason
you would put one in a program is to have a delay. Deleting them will
not make real programs run any faster, so it would be pointless.
Historically, GNU CC has not deleted ``empty'' loops under the
assumption that the most likely reason you would put one in a program is
to have a delay, so deleting them will not make real programs run any
faster.
It would be different if optimization of a nonempty loop could produce
an empty one. But this generally can't happen.
However, the rationale here is that optimization of a nonempty loop
cannot produce an empty one, which holds for C but is not always the
case for C++.
Moreover, with @samp{-funroll-loops} small ``empty'' loops are already
removed, so the current behavior is both sub-optimal and inconsistent
and will change in the future.
@item
Making side effects happen in the same order as in some other compiler.