This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug optimization/12468] empty loop not eliminated as dead code


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12468



------- Additional Comments From bh at techhouse dot brown dot edu  2003-09-30 20:14 -------
Subject: Re:  empty loop not eliminated as dead code

On Tue, Sep 30, 2003 at 07:36:55PM -0000, pinskia at gcc dot gnu dot org wrote:
> Deleting "empty" loops.
>
> Historically, GCC 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++.

This is false even for C: it's not too hard to create a case where all
the statements inside the loop can be hoisted out (everything is
loop-invariant or based on iteration variables) -- especially with
ifdefs, if(CONSTANT), or with the pure and const function attributes.  I
filed a bug report for an "empty" loop because gcc was only not killing
the loop; it hoisted all the code out of my loop just fine.

If the programmer is wanting to waste time, the programmer should
declare i to be volatile.  Perhaps gcc should also support
-fno-delete-empty-loops to support legacy code.


> Moreover, with -funroll-loops small "empty" loops are already removed,
> so the current behavior is both sub-optimal and inconsistent and will
> change in the future.

If the current behaviour is slated to be fixed, should it not be a bug
report / feature request entered into bugzilla?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]