This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [doc] empty loops
Richard Henderson wrote:
On Wed, Nov 24, 2004 at 07:41:01PM +0100, Zdenek Dvorak wrote:
is this really true? The last time I checked we did not remove
provably finite empty loops (except for those that do not iterate too
much, that may get removed as a side effect of unrolling), although
patch for this is pending for some time.
It's certainly ok to document that we intend to remove such loops,
even if we don't actually do it now.
I confused myself with the example. I meant it to point out that
even non-empty C loops can be optimized to empty ones. How about this
adjusted wording that leaves it open to when such loops actually get
deleted.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk
2004-11-24 Nathan Sidwell <nathan@codesourcery.com>
* trouble.texi (Non-bugs): Clarify empty loop removal.
Index: doc/trouble.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/trouble.texi,v
retrieving revision 1.29
diff -c -3 -p -r1.29 trouble.texi
*** doc/trouble.texi 5 Nov 2004 01:36:57 -0000 1.29
--- doc/trouble.texi 25 Nov 2004 12:17:25 -0000
*************** to have a delay, so deleting them will n
*** 1217,1229 ****
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++.
@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.
@item
Making side effects happen in the same order as in some other compiler.
--- 1217,1250 ----
faster.
However, the rationale here is that optimization of a nonempty loop
! 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
! 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.