A new ia32 backend

A new ia32 backend

[Richard Henderson]

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.

Central to this goal is a more accurate machine description:

  * No more cc0, but instead an explicit flags register.  This allows
    the scheduler more freedom wrt placement of comparison instructions.
    It allows combine to search for places where arithmetic obviates the
    need for an explicit compare, rather than leaving things to chance.

  * Instruction selection is done in full view of the scheduler.  Previously,
    we would do instruction selection at assembly output time, and the
    scheduler was only give approximations, limiting its effectiveness.
    With the more accurate information, it is able to bundle instructions
    into the 4-1-1 uop sequences that the Pentium II's decoders like to see.

In addition, there are a few generic optimizations:

  * An rtl-based peephole pass that is run before sched2.  In addition
    to replacing sequences of instructions, it is also able to find 
    free registers and allocate them as scratches.  This is a generalization
    of the PGCC -friscify pass.

  * Recognition of extension-dependant GIVs.  This shows up in a loop like

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

    When performing the address arithmetic on `array', we must sign-extend
    `s' from a short to a ptrdiff_t.  Previously when seeing the extension,
    we would just throw up our hands and not optimize.

  * 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.

  * 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.

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.

Because we branched so long ago, and the gcc project has been moving so
rapidly, the merge process will not be simple.  Diffs taken from the branch
do not apply cleanly, and there are changes that have gone into gcc that
should not be lost in the transition.

That the patches don't apply directly is actually a good thing.  The code
should be peer-reviewed, which is easily done concurrently with fixing up
patch problems.

So: I've put the code out on 

  ftp://egcs.cygnus.com/pub/egcs/snapshots/p2/p2-19990615.tar.bz2

It contains

-r--r--r-- rth/cygnus  1063110 1999-06-12 18:30 p2/d-p2-pass0
-r--r--r-- rth/cygnus   922536 1999-06-12 18:30 p2/d-p2-raw-1
-r--r--r-- rth/cygnus    46751 1999-06-12 18:33 p2/d-p2-raw-2
-r--r--r-- rth/cygnus    30242 1999-06-12 18:30 p2/d-p2-raw-3
-r--r--r-- rth/cygnus    97077 1999-06-12 18:30 p2/reg-stack.c
-r--r--r-- rth/cygnus   144559 1999-06-12 18:31 p2/i386.c
-r--r--r-- rth/cygnus    96498 1999-06-12 18:31 p2/i386.h
-r--r--r-- rth/cygnus   231903 1999-06-12 18:31 p2/i386.md
-r--r--r-- rth/cygnus    33084 1999-06-12 18:32 p2/ChangeLog.P2

The files d-p2-raw-* are diffs directly out of cvs, which is kind
of confusing because different things went in to different branches
at different times.  I'm fairly sure I got it all.

The file d-p2-pass0 is a first pass approximation at applying the
patches to egcs mainline.  It compiles, but I guarantee it does not
work -- it segv's building libgcc2.

Because of the massive changes, reg-stack.c, and i386.* are the
complete files off the branch.  This should help figuring out what
to do with some of the egcs changes since the branch was created.

Over the coming weeks, I will appreciate your help in cleaning up
this code so that it can go into gcc mainline.  Optimistically, I
think we could have this done by August 1.  However, I do not want
this to impact the gcc 2.95 release process, so if we have to put
the merge aside temporarily, so be it.

Enjoy.


r~

Re: A new ia32 backend

[craig]

Awesome!  I mention this now on my g77 page, at
< http://world.std.com/~burley/g77.html#development >.  Let me know
if my writeup needs changing.

        tq vm, (burley)

Re: 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

Re: A new ia32 backend

[Gerald Pfeifer]

On Tue, 15 Jun 1999, 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.

Cool!  Richard, I'd like to add this as an annoucement on our home page.

Would you mind destilling a paragraph from your full announcement? I guess
we will also want to publish the announcement itself, as we have done in
the case of

  February 26, 1999 
      Richard Henderson of Cygnus Solutions has donated a major rewrite of
      the control flow analysis pass of the compiler. 

I suggest that you either go ahead and install changes to our home page
as well as a new file ia32.html (or similiar) or contact me by private
e-mail and we'll handle that HTML stuff together.

(In the first case, please submit these as patches to egcs-patches
afterwards.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: A new ia32 backend

[Richard Henderson]

On Wed, Jun 16, 1999 at 09:37:01PM +0200, Toon Moene wrote:
> >   * 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).

Actually, it can help some Fortran inner loops.  It requires that the
loop access both single and double precision data with the same final
index.  Something like

	float f[10][10];
	double d[10][10];

	for (i = 0; i < 10; ++i)
	  for (j = 0; j < 10; ++j)
	    res[j] += f[i][j] + d[i][j];

Previously we'd get (loosely)

	f' = &f[i];
	d' = &d[i];
	for (i = 0; i < 10; ++i)
	  {
	    f'' = &f'[0];
	    d'' = &d'[0];
	    res' = &res[0];
	    for (j = 0; j < 10; ++j)
	      {
	        *res' = *f'' + *d'';
	        res'++, f''++, d''++;
	      }
	    f'++;
	    d'++;
	  }

With the rearrangement we're more likely to see f'' and d'' combined:

	f' = &f[i];
	d' = &d[i];
	for (i = 0; i < 10; ++i)
	  {
	    res' = &res[0];
	    for (j = 0; j < 10; ++j)
	      *res'++ = *(f' + j*4) + *(d' + j*8);
	  }

Which uses one less register, and needs one less increment in the
inner loop.



r~

Re: A new ia32 backend

[Joe Buck]

 
On Tue, 15 Jun 1999, 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.

Gerald Pfeifer writes:
> Cool!  Richard, I'd like to add this as an annoucement on our home page.

Please make sure it's clear that the new back end won't be in gcc-2.95.

Re: A new ia32 backend

[Joe Buck]

 
On Tue, 15 Jun 1999, 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.

Gerald Pfeifer writes:
> Cool!  Richard, I'd like to add this as an annoucement on our home page.

Please make sure it's clear that the new back end won't be in gcc-2.95.

Re: 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

Re: A new ia32 backend

[Gerald Pfeifer]

On Tue, 15 Jun 1999, 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.

Cool!  Richard, I'd like to add this as an annoucement on our home page.

Would you mind destilling a paragraph from your full announcement? I guess
we will also want to publish the announcement itself, as we have done in
the case of

  February 26, 1999 
      Richard Henderson of Cygnus Solutions has donated a major rewrite of
      the control flow analysis pass of the compiler. 

I suggest that you either go ahead and install changes to our home page
as well as a new file ia32.html (or similiar) or contact me by private
e-mail and we'll handle that HTML stuff together.

(In the first case, please submit these as patches to egcs-patches
afterwards.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: A new ia32 backend

[Richard Henderson]

On Wed, Jun 16, 1999 at 09:37:01PM +0200, Toon Moene wrote:
> >   * 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).

Actually, it can help some Fortran inner loops.  It requires that the
loop access both single and double precision data with the same final
index.  Something like

	float f[10][10];
	double d[10][10];

	for (i = 0; i < 10; ++i)
	  for (j = 0; j < 10; ++j)
	    res[j] += f[i][j] + d[i][j];

Previously we'd get (loosely)

	f' = &f[i];
	d' = &d[i];
	for (i = 0; i < 10; ++i)
	  {
	    f'' = &f'[0];
	    d'' = &d'[0];
	    res' = &res[0];
	    for (j = 0; j < 10; ++j)
	      {
	        *res' = *f'' + *d'';
	        res'++, f''++, d''++;
	      }
	    f'++;
	    d'++;
	  }

With the rearrangement we're more likely to see f'' and d'' combined:

	f' = &f[i];
	d' = &d[i];
	for (i = 0; i < 10; ++i)
	  {
	    res' = &res[0];
	    for (j = 0; j < 10; ++j)
	      *res'++ = *(f' + j*4) + *(d' + j*8);
	  }

Which uses one less register, and needs one less increment in the
inner loop.



r~

Re: A new ia32 backend

[craig]

Awesome!  I mention this now on my g77 page, at
< http://world.std.com/~burley/g77.html#development >.  Let me know
if my writeup needs changing.

        tq vm, (burley)

A new ia32 backend

[Richard Henderson]

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.

Central to this goal is a more accurate machine description:

  * No more cc0, but instead an explicit flags register.  This allows
    the scheduler more freedom wrt placement of comparison instructions.
    It allows combine to search for places where arithmetic obviates the
    need for an explicit compare, rather than leaving things to chance.

  * Instruction selection is done in full view of the scheduler.  Previously,
    we would do instruction selection at assembly output time, and the
    scheduler was only give approximations, limiting its effectiveness.
    With the more accurate information, it is able to bundle instructions
    into the 4-1-1 uop sequences that the Pentium II's decoders like to see.

In addition, there are a few generic optimizations:

  * An rtl-based peephole pass that is run before sched2.  In addition
    to replacing sequences of instructions, it is also able to find 
    free registers and allocate them as scratches.  This is a generalization
    of the PGCC -friscify pass.

  * Recognition of extension-dependant GIVs.  This shows up in a loop like

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

    When performing the address arithmetic on `array', we must sign-extend
    `s' from a short to a ptrdiff_t.  Previously when seeing the extension,
    we would just throw up our hands and not optimize.

  * 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.

  * 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.

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.

Because we branched so long ago, and the gcc project has been moving so
rapidly, the merge process will not be simple.  Diffs taken from the branch
do not apply cleanly, and there are changes that have gone into gcc that
should not be lost in the transition.

That the patches don't apply directly is actually a good thing.  The code
should be peer-reviewed, which is easily done concurrently with fixing up
patch problems.

So: I've put the code out on 

  ftp://egcs.cygnus.com/pub/egcs/snapshots/p2/p2-19990615.tar.bz2

It contains

-r--r--r-- rth/cygnus  1063110 1999-06-12 18:30 p2/d-p2-pass0
-r--r--r-- rth/cygnus   922536 1999-06-12 18:30 p2/d-p2-raw-1
-r--r--r-- rth/cygnus    46751 1999-06-12 18:33 p2/d-p2-raw-2
-r--r--r-- rth/cygnus    30242 1999-06-12 18:30 p2/d-p2-raw-3
-r--r--r-- rth/cygnus    97077 1999-06-12 18:30 p2/reg-stack.c
-r--r--r-- rth/cygnus   144559 1999-06-12 18:31 p2/i386.c
-r--r--r-- rth/cygnus    96498 1999-06-12 18:31 p2/i386.h
-r--r--r-- rth/cygnus   231903 1999-06-12 18:31 p2/i386.md
-r--r--r-- rth/cygnus    33084 1999-06-12 18:32 p2/ChangeLog.P2

The files d-p2-raw-* are diffs directly out of cvs, which is kind
of confusing because different things went in to different branches
at different times.  I'm fairly sure I got it all.

The file d-p2-pass0 is a first pass approximation at applying the
patches to egcs mainline.  It compiles, but I guarantee it does not
work -- it segv's building libgcc2.

Because of the massive changes, reg-stack.c, and i386.* are the
complete files off the branch.  This should help figuring out what
to do with some of the egcs changes since the branch was created.

Over the coming weeks, I will appreciate your help in cleaning up
this code so that it can go into gcc mainline.  Optimistically, I
think we could have this done by August 1.  However, I do not want
this to impact the gcc 2.95 release process, so if we have to put
the merge aside temporarily, so be it.

Enjoy.


r~

Re: A new ia32 backend

[craig]

>Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 
>
>>...
>>	while (a--) { /* nothing dependant on a */ }
>>    becomes
>>	if (a) do { ... } while (--a);
>>...
>
>Is it really equivalent? Even if `(a == 0)' just before
>the two lines?

No, good point, there needs to be an `else --a;' added to the
`if' clause.  (Presumably the actual code in the compiler is
correct, but it's always good to check, as well as make sure
these email'ed "doclets" are correct as well!)

        tq vm, (burley)

Re: A new ia32 backend

[craig]

>>Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 
>>
>>>...
>>>	while (a--) { /* nothing dependant on a */ }
>>>    becomes
>>>	if (a) do { ... } while (--a);
>>>...
>>
>>Is it really equivalent? Even if `(a == 0)' just before
>>the two lines?
>
>No, good point, there needs to be an `else --a;' added to the
>`if' clause.  (Presumably the actual code in the compiler is
>correct, but it's always good to check, as well as make sure
>these email'ed "doclets" are correct as well!)

Sigh.  Forget the `else', what is needed is a simple `--a;' after
the entire `if'.

        tq vm, (burley)

Re: A new ia32 backend

[Norbert Berzen]

Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 

>...
>	while (a--) { /* nothing dependant on a */ }
>    becomes
>	if (a) do { ... } while (--a);
>...

Is it really equivalent? Even if `(a == 0)' just before
the two lines?

-- 
Norbert

Re: A new ia32 backend

[Mike Stump]

I tracked down the failure in compiling libgcc.a with rth's new p2
work.  It dies checking:

(insn 21 20 50 (use (reg/i:SI 0 eax)) -1 (insn_list 39 (insn_list 20 (nil)))
    (expr_list:REG_DEAD (reg/i:SI 0 eax)
        (nil)))

in stack_regs_mentioned from find_cross_jump from jump_optimize_1 from
jump_optimize from reg_to_stack.  In our case, pat is nil.  In the
original compiler, something about the rtl causes it to not come in
and check it, though I don't know exactly what.

My solution was to put:

  if (pat == 0)
=>  return 0;

at the top of stack_regs_mentioned.  Below is the cut down testcase:

int i;
 
int __fixunsdfsi (float a) {
  if (a >= 2)
    return a;
}

After this is fixed (or worked around as the case may be), we then hit
a problem compiling the below with -O2 -fPIC:

struct bb {
  long zero_word;
};
 
static int trace_init = 0;
 
void __bb_init_trace_func (struct bb *blocks, unsigned long blockno) {
 
  register int eax_ __asm__("eax");
  register int ecx_ __asm__("ecx");
  register int edx_ __asm__("edx");
  register int esi_ __asm__("esi");
  __asm__ __volatile__ (        "push{l} %0\n\t"        "push{l} %1\n\t"       \
 "push{l} %2\n\t"        "push{l} %3"    : : "r"(eax_), "r"(ecx_), "r"(edx_), "\
r"(esi_));
 
  if (!blocks->zero_word)
    {
      if (!trace_init)
        {
          __bb_init_prg ();
        }
    }
}

I haven't tracked it down yet.  More next week.

Re: A new ia32 backend

[Richard Henderson]

On Fri, Jun 18, 1999 at 07:19:01PM -0700, Mike Stump wrote:
> I tracked down the failure in compiling libgcc.a with rth's new p2
> work.  It dies checking:
> 
> (insn 21 20 50 (use (reg/i:SI 0 eax)) -1 (insn_list 39 (insn_list 20 (nil)))
>     (expr_list:REG_DEAD (reg/i:SI 0 eax)
>         (nil)))
> 
> in stack_regs_mentioned from find_cross_jump from jump_optimize_1 from
> jump_optimize from reg_to_stack.  In our case, pat is nil.  In the
> original compiler, something about the rtl causes it to not come in
> and check it, though I don't know exactly what.

The original compiler expects to send insns, the new one expected
patterns.  The solution is to merge Jan's reg-stack insn mode patch
from April.

I'll be checking that in momentarily.


r~

Re: A new ia32 backend

[Richard Henderson]

On Wed, Jun 16, 1999 at 01:53:51PM -0000, craig@jcb-sc.com wrote:
> Sigh.  Forget the `else', what is needed is a simple `--a;' after
> the entire `if'.

Yes, you've caught me in a typo.

The code actually does `a = -1' (kinda) after the loop --

  /* Set the correct final value at the end of the loop.  This will be
     deleted if it is not used. */
  if (GET_CODE (comparison) != NE)
    {
      insn = gen_move_insn (bl->biv->dest_reg, 
			    gen_rtx_PLUS (GET_MODE (bl->biv->dest_reg),
					  bl->biv->dest_reg,
					  loop_info->final_value));
    }
  else
    {
      insn = gen_move_insn (bl->biv->dest_reg, loop_info->final_value);
    }


r~

Re: A new ia32 backend

[Richard Henderson]

On Fri, Jun 18, 1999 at 07:19:01PM -0700, Mike Stump wrote:
> I tracked down the failure in compiling libgcc.a with rth's new p2
> work.  It dies checking:
> 
> (insn 21 20 50 (use (reg/i:SI 0 eax)) -1 (insn_list 39 (insn_list 20 (nil)))
>     (expr_list:REG_DEAD (reg/i:SI 0 eax)
>         (nil)))
> 
> in stack_regs_mentioned from find_cross_jump from jump_optimize_1 from
> jump_optimize from reg_to_stack.  In our case, pat is nil.  In the
> original compiler, something about the rtl causes it to not come in
> and check it, though I don't know exactly what.

The original compiler expects to send insns, the new one expected
patterns.  The solution is to merge Jan's reg-stack insn mode patch
from April.

I'll be checking that in momentarily.


r~

Re: A new ia32 backend

[Mike Stump]

I tracked down the failure in compiling libgcc.a with rth's new p2
work.  It dies checking:

(insn 21 20 50 (use (reg/i:SI 0 eax)) -1 (insn_list 39 (insn_list 20 (nil)))
    (expr_list:REG_DEAD (reg/i:SI 0 eax)
        (nil)))

in stack_regs_mentioned from find_cross_jump from jump_optimize_1 from
jump_optimize from reg_to_stack.  In our case, pat is nil.  In the
original compiler, something about the rtl causes it to not come in
and check it, though I don't know exactly what.

My solution was to put:

  if (pat == 0)
=>  return 0;

at the top of stack_regs_mentioned.  Below is the cut down testcase:

int i;
 
int __fixunsdfsi (float a) {
  if (a >= 2)
    return a;
}

After this is fixed (or worked around as the case may be), we then hit
a problem compiling the below with -O2 -fPIC:

struct bb {
  long zero_word;
};
 
static int trace_init = 0;
 
void __bb_init_trace_func (struct bb *blocks, unsigned long blockno) {
 
  register int eax_ __asm__("eax");
  register int ecx_ __asm__("ecx");
  register int edx_ __asm__("edx");
  register int esi_ __asm__("esi");
  __asm__ __volatile__ (        "push{l} %0\n\t"        "push{l} %1\n\t"       \
 "push{l} %2\n\t"        "push{l} %3"    : : "r"(eax_), "r"(ecx_), "r"(edx_), "\
r"(esi_));
 
  if (!blocks->zero_word)
    {
      if (!trace_init)
        {
          __bb_init_prg ();
        }
    }
}

I haven't tracked it down yet.  More next week.

Re: A new ia32 backend

[Richard Henderson]

On Wed, Jun 16, 1999 at 01:53:51PM -0000, craig@jcb-sc.com wrote:
> Sigh.  Forget the `else', what is needed is a simple `--a;' after
> the entire `if'.

Yes, you've caught me in a typo.

The code actually does `a = -1' (kinda) after the loop --

  /* Set the correct final value at the end of the loop.  This will be
     deleted if it is not used. */
  if (GET_CODE (comparison) != NE)
    {
      insn = gen_move_insn (bl->biv->dest_reg, 
			    gen_rtx_PLUS (GET_MODE (bl->biv->dest_reg),
					  bl->biv->dest_reg,
					  loop_info->final_value));
    }
  else
    {
      insn = gen_move_insn (bl->biv->dest_reg, loop_info->final_value);
    }


r~

Re: A new ia32 backend

[craig]

>>Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 
>>
>>>...
>>>	while (a--) { /* nothing dependant on a */ }
>>>    becomes
>>>	if (a) do { ... } while (--a);
>>>...
>>
>>Is it really equivalent? Even if `(a == 0)' just before
>>the two lines?
>
>No, good point, there needs to be an `else --a;' added to the
>`if' clause.  (Presumably the actual code in the compiler is
>correct, but it's always good to check, as well as make sure
>these email'ed "doclets" are correct as well!)

Sigh.  Forget the `else', what is needed is a simple `--a;' after
the entire `if'.

        tq vm, (burley)

Re: A new ia32 backend

[craig]

>Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 
>
>>...
>>	while (a--) { /* nothing dependant on a */ }
>>    becomes
>>	if (a) do { ... } while (--a);
>>...
>
>Is it really equivalent? Even if `(a == 0)' just before
>the two lines?

No, good point, there needs to be an `else --a;' added to the
`if' clause.  (Presumably the actual code in the compiler is
correct, but it's always good to check, as well as make sure
these email'ed "doclets" are correct as well!)

        tq vm, (burley)

Re: A new ia32 backend

[Norbert Berzen]

Richard Henderson wrote in < 19990615224736.A29894@cygnus.com >: 

>...
>	while (a--) { /* nothing dependant on a */ }
>    becomes
>	if (a) do { ... } while (--a);
>...

Is it really equivalent? Even if `(a == 0)' just before
the two lines?

-- 
Norbert