From c2a2650529c07faeb521ac3bdb1453b2938f648a Mon Sep 17 00:00:00 2001 From: Gerald Pfeifer Date: Wed, 30 Dec 1998 06:28:05 +0100 Subject: [PATCH] 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 --- gcc/ChangeLog | 5 +++++ gcc/gcc.texi | 18 ++++++++++++------ 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 263ec60b431..8629ce799f4 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +Mon Dec 28 19:26:32 1998 Gerald Pfeifer + + * 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 * sparc.c (input_operand): Recognize (const (constant_p_rtx)). diff --git a/gcc/gcc.texi b/gcc/gcc.texi index bf454e17838..06551cd036c 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. -- 2.30.2