This is the mail archive of the gcc-patches@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]

Re: Loop unrolling


On Mon, 1 Jun 1998, Mike Stump wrote:
> I don't think this should go in the docs.  I think it is a bug in the
> unroller that gcc optimizes away an empty loop.  I think this should
> be fixed.  I think the docs can admit the current bug, but should not
> call it anything but a bug.

I'm the one who started this monster thread, and actually I believe that
John Carr <jfc@mit.edu>, Branko Cibej <branko.cibej@hermes.si>, Martin
von Loewis <martin@mira.isdn.cs.tu-berlin.de> have provided examples that 
empty loops _should_ get removed.

Jeff, what happened to my patch? You neither commented on it nor has
it been installed. :-(

Please find below a typo-fixed version of my patch. (Thanks go to
Craig Burley <burley@gnu.org>!)

Gerald


Mon Jun  1 22:28:31 1998  Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>

	* ``Empty'' loops sometimes do get deleted and can indeed be
	generated by optimization.
	  

Index: gcc.texi
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/gcc.texi,v
retrieving revision 1.11
diff -r1.11 gcc.texi
2004,2006c2004,2007
< 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.
---
> GNU CC does not delete ``empty'' loops because (historically) the most
> likely reason you would put one in a program was to have a delay.
> Deleting these will not make real programs run any faster, so it would 
> be pointless.
2008,2009c2009,2015
< It would be different if optimization of a nonempty loop could produce
< an empty one.  But this generally can't happen.
---
> However, the rationale here was that optimization of a nonempty loop
> cannot produce an empty one, which holds for C but is not the case for
> C++ in general.
> 
> Moreover, with @samp{-funroll-loops} small ``empty'' loops indeed are
> removed, so the current behavior is both sub-optimal and inconsistent
> and may well change in the future. 






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