A new ia32 backend

[Toon Moene]

Richard Henderson wrote:

> On behalf of Cygnus, I am pleased to be able to donate a new back end
> for the IA-32 architecture.  The work was done under contract to Intel,
> and focused on better optimization for the Pentium II core.

Wow, great - worth of mention on our Front Page (Gerald?) :-)

> In addition, there are a few generic optimizations:

>   * Recognition of extension-dependant GIVs.  This shows up in a loop like
> 
>         short s;
>         for (s = 0; s < 10; ++s)
>           array[s] = 0;

Good; I hope Intel paid for this before they realized that this
optimization is even more useful for the following code (just because it
is more ubiquitous):

        int s;
        for (s = 0; s < 10; ++s)
          array[s] = 0;

on architectures where sizeof(something *) > sizeof(int) [ see for
instance David Mosberger-Tang's LinuxExpo '97 paper on optimization
strategies for the Alpha ]

Now, of course, this would also help the IA-64, and as far as we know,
it could use all the help it can get ;-)

A nice side benefit of this optimization is that we can now remove all
the special code in the Fortran frontend for promoting index
computations to ptr-mode size that you so aptly wrote in the early days
of egcs (i.e., in the second half of '97).

> 
>   * Recognition of certain forms of loop-carried post-decrement.  Primarily,
> 
>         while (a--) { /* nothing dependant on a */ }
>     becomes
>         if (a) do { ... } while (--a);
> 
>     which removes a temporary and is friendlier to the register allocator.

Ah, this is akin to the four-letter-hack to the Fortran Fronted I wrote
in November '95 to accomplish the same thing.

Note, as several have remarked upon - the code above is only correct if
`a' dies right after the loop.

>   * Reorganize certain forms of (A*B)+(C*D) that occur in multidimensional
>     array access.  This will become ((A*B')+(C*D'))*F, where F is a power
>     of two factor in common to B and D.  This allows better use of scaled
>     index addressing modes, and generally better GIV combination.

Well, this won't help Fortran inner loops, but it might simplify some
code in non-inner loops (which get all the integer multiplies moved out
of the inner loop by invariant code motion).

> The work was done primarily by Bob Manson and myself between November 1998
> and April 1999.  Ulrich Drepper, Stan Cox, and Andrew Haley provided enormous
> help in isolating code generation problems.

Yeah, lots of thanks to this crew !

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html