diff options
| author | Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> | 1998-12-30 06:28:05 +0100 |
|---|---|---|
| committer | Gerald Pfeifer <gerald@gcc.gnu.org> | 1998-12-30 05:28:05 +0000 |
| commit | c2a2650529c07faeb521ac3bdb1453b2938f648a (patch) | |
| tree | 7c67d5b2f70813a6df0a6dcbc953fa4d5b25eead | |
| parent | 30dfe54ae2534ed75ce025884ead2d09dc85c0ce (diff) | |
| download | gcc-c2a2650529c07faeb521ac3bdb1453b2938f648a.zip gcc-c2a2650529c07faeb521ac3bdb1453b2938f648a.tar.gz gcc-c2a2650529c07faeb521ac3bdb1453b2938f648a.tar.bz2 | |
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
| -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. |