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

Re: [doc] empty loops

On Thu, 25 Nov 2004 12:24:01 +0000, Nathan Sidwell
<> wrote:
> 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.

I always thought it was funny we don't remove empty loops.  Especially as
we don't preserve the number of iterations of an empty loop with -funroll-loops
(should be worth a note in the documentation, too).

Also, playing with empty loops, I was shocked after looking at the code
created for the recursive variant of

void foo(void)
        for (int i=0; i<1000; ++i)


static inline void foo3(int i)
        if (!(i<1000))
void foo4(void)

I thought Zednek contributed a patch for optimizing these
tail-recursive functions
some time ago.  Even for a standard n! implementation we suck.

Btw. the intel compiler does not remove the empty loop in foo (but "unrolls" it
5 times), but removes the recursive variant completely.  But it cannot, too,
optimize the tail-recursive n! implementation.

Oh well,

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