Loop unroll fixes

[Mark Mitchell]

--On Wednesday, October 24, 2001 03:51:39 AM -0500 Zoltan Hidvegi 
<hzoli@hzoli.2y.net> wrote:

>> Unfortunately, one of the first principles of compilers is that the
>> language specification is honored at all costs -- even if that has
>> performance implications.  Saying that no sane person would write
>
> Yes, but sometimes I wish I can have a flag that allows the compiler to
> not generate extra code for such extreme cases.  The -O3 flag on the IBM
> C/C++ does that.  Actually, for this infinite loop, the IBM compiler,
> even with just -O runs the loop 2^word_size/increment times, i.e. it is
> worse than us.  2^32 iterations is `almost infinite' and in 64-bit mode
> 2^64 iterations is really practically infinite.

It's fine for IBM to do this; they presumably do what serves their
users.

For GCC, it would be against our conventions to do this with -O3,
but we could have -funsafe-loops (bad name, but you get the idea) 
corresponding to -ffast-math.  (GCC should generate correct code
with any -O option.)

Actually, 2^32 isn't that infinite.  4 billion operations doesn't
take that long on a machine that can do several hundred million
operations per second.  2^64 is still relatively close to infinite,
but just wait a few year.

> The standard defines the unsigned overflow as modulo 2^word_size
> operation, but the result of signed overflow is undefined.

Ah, good; if the loop variable is signed, then you could apply your
optimization.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com