diff options
| -rw-r--r-- | gcc/ChangeLog | 5 | ||||
| -rw-r--r-- | gcc/gcc.texi | 18 |
2 files changed, 17 insertions, 6 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 263ec60..8629ce7 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -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)). diff --git a/gcc/gcc.texi b/gcc/gcc.texi index bf454e1..06551cd 100644 --- a/gcc/gcc.texi +++ b/gcc/gcc.texi @@ -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. - -It would be different if optimization of a nonempty loop could produce -an empty one. But this generally can't happen. +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. + +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. |