diff options
| author | Nathan Sidwell <nathan@codesourcery.com> | 2004-12-08 08:42:15 +0000 |
|---|---|---|
| committer | Nathan Sidwell <nathan@gcc.gnu.org> | 2004-12-08 08:42:15 +0000 |
| commit | e6aef9696474198372ccd66e8a5588b30ffbf93f (patch) | |
| tree | 20189c024607031ef756df0f166ea5e2b2a3d37d /gcc | |
| parent | db24eb1f4fcc6fa8330376179278261e02b717b5 (diff) | |
| download | gcc-e6aef9696474198372ccd66e8a5588b30ffbf93f.zip gcc-e6aef9696474198372ccd66e8a5588b30ffbf93f.tar.gz gcc-e6aef9696474198372ccd66e8a5588b30ffbf93f.tar.bz2 | |
* doc/trouble.texi (Non-bugs): Clarify empty loop removal.
From-SVN: r91864
Diffstat (limited to 'gcc')
| -rw-r--r-- | gcc/ChangeLog | 4 | ||||
| -rw-r--r-- | gcc/doc/trouble.texi | 31 |
2 files changed, 30 insertions, 5 deletions
diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 52a8b92..1579cb3 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2004-12-08 Nathan Sidwell <nathan@codesourcery.com> + + * doc/trouble.texi (Non-bugs): Clarify empty loop removal. + 2004-12-08 Uros Bizjak <uros@kss-loka.si> * config/i386/i386.c (output_387_binary_op, diff --git a/gcc/doc/trouble.texi b/gcc/doc/trouble.texi index 58a46f9..01c0c19 100644 --- a/gcc/doc/trouble.texi +++ b/gcc/doc/trouble.texi @@ -1217,13 +1217,34 @@ 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++. +cannot produce an empty one. This held for carefully written C compiled +with less powerful optimizers but is not always the case for carefully +written C++ or with more powerful optimizers. @opindex funroll-loops -Moreover, with @option{-funroll-loops} small ``empty'' loops are already -removed, so the current behavior is both sub-optimal and inconsistent -and will change in the future. +Thus GCC will remove operations from loops whenever it can determine +those operations are not externally visible (apart from the time taken +to execute them, of course). As GCC improves, it will remove the loop +itself. Indeed, with @option{-funroll-loops} small loops can already be +removed, so leaving an empty non-unrolled loop is both sub-optimal and +inconsistent. + +Be aware of this when performing timing tests, for instance the +following loop can be completely removed, provided +@code{some_expression} can provably not change any global state. + +@smallexample +@{ + int sum = 0; + int ix; + + for (ix = 0; ix != 10000; ix++) + sum += some_expression; +@} +@end smallexample + +Even though @code{sum} is accumulated in the loop, no use is made of +that summation, so the accumulation can be removed. @item Making side effects happen in the same order as in some other compiler. |