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


mrs@wrs.com (Mike Stump) said:
> > From: Horst von Brand <vonbrand@sleipnir.valparaiso.cl>
> > mrs@wrs.com (Mike Stump) said:

> > [...]

[...]

> > That is a horribly broken idea.

> What you mean to say is that people that expect gcc to correctly
> compile old style timing loops are wrong for expecting it to work, and
> that you think we should break their existing code, renig on our
> documented promise to not break their code, and remove this documented
> GNU extension from gcc, and break their code.

How many people are really using empty timing loops? How many of them use
different gccs for timing loops and expect them to time the same? If I was
to write a timing loop, I certainly wouldn't rely on gcc to give me the
same timing everytime: The loop that computes BogoMIPS inside Linux is
written in assembly, and for good reason. That's what I think is a horribly
broken idea. That, and the misguided "niceness" to programmers that don't
know better and write empty loops for timing in C. 

As you state, this adds hair to the compiler (which is widely considered
way too hairy as it is). Several rather ad hoc (and very un-C-like, IMHO)
lexical conventions for expressing "purposely empty loops" have been
proposed.

There was a flamewar not long ago (in comp.lang.c, IIRC) where somebody
complained bitterly that the compiler would not execute his statements
exactly as written. It was very forcefully stated that the compiler had to
give results "as if" it did was was written down; if it knew a better way
to do what it was asked to do, by all means use it! The C compiler today
(with weird CPUs, caches, ...) is a rather different animal than the
simplistic C compiler of early Unix systems and PCs.

[...]

> That is a fine thing to say, but it is better to express it that way
> so that people understand the totality of your statement, otherwise
> people that don't know better are led to the mistaken conclusion that
> I am just misguided and that you are obviously correct.

OK, maybe I didn't state both sides evenly. But please show cases of people
that really depend on this rather bizarre behaviour of gcc.

> > That way you have to get non-standard lexical information down to
> > the loop-optimizer.

> And?

Unecesary hair.

> > The data paths for that surely aren't in place,

> They mostly are, but some icky code would have to be added to get the
> last ounce of performance out of the optimizer, if one wanted it.

Better leave the icky code out. As the old maxim says: "The code that costs
the least to program, costs least runtime and least memory space, and which
moreover costs least to document and maintain is the code that isn't
there." Icky code is fine, so long as you can show a clear need for it. In
this case, I just can't see any.
-- 
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viņa del Mar, Chile                               +56 32 672616


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