HOST_WIDE_INT = long long patch

HOST_WIDE_INT = long long patch

[John Carr]

This fixes a bug in strength reduction on SPARC when HOST_WIDE_INT is
long long: multiplying by -1 gets the wrong answer.  It may not be the
best fix.  Please review.

Mon Apr  6 18:38:20 1998  John Carr  <jfc@mit.edu>

	* expmed.c (expand_mult): When HOST_WIDE_INT is wider than int do not
	call synth_mult with a negative multiplier value.

===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/expmed.c,v
retrieving revision 1.11
diff -c -3 -p -r1.11 expmed.c
*** expmed.c	1998/04/04 17:37:49	1.11
--- expmed.c	1998/04/06 22:37:43
*************** expand_mult (mode, op0, op1, target, uns
*** 2212,2218 ****
        mult_cost = rtx_cost (gen_rtx_MULT (mode, op0, op1), SET);
        mult_cost = MIN (12 * add_cost, mult_cost);
  
!       synth_mult (&alg, val, mult_cost);
  
        /* This works only if the inverted value actually fits in an
  	 `unsigned int' */
--- 2212,2221 ----
        mult_cost = rtx_cost (gen_rtx_MULT (mode, op0, op1), SET);
        mult_cost = MIN (12 * add_cost, mult_cost);
  
!       if (HOST_BITS_PER_WIDE_INT == HOST_BITS_PER_INT || val >= 0)
! 	synth_mult (&alg, val, mult_cost);
!       else
! 	alg.cost = mult_cost;
  
        /* This works only if the inverted value actually fits in an
  	 `unsigned int' */

Re: HOST_WIDE_INT = long long patch

[Joern Rennecke]

> This fixes a bug in strength reduction on SPARC when HOST_WIDE_INT is
> long long: multiplying by -1 gets the wrong answer.  It may not be the
> best fix.  Please review.

Why does it fail?  Would it be possible to fix the bug by using
HOST_WIDE_INT instead of int / long more consistently?

Re: HOST_WIDE_INT = long long patch

[Jeffrey A Law]

  In message < 199804062243.SAA04832@jfc. >you write:
  > 
  > This fixes a bug in strength reduction on SPARC when HOST_WIDE_INT is
  > long long: multiplying by -1 gets the wrong answer.  It may not be the
  > best fix.  Please review.
  > 
  > Mon Apr  6 18:38:20 1998  John Carr  <jfc@mit.edu>
  > 
  > 	* expmed.c (expand_mult): When HOST_WIDE_INT is wider than int do not
  > 	call synth_mult with a negative multiplier value.
I checked in a fix to synth_mult for multiplying by -1 on Apr 3.  In
theory your patch shouldn't be necessary anymore.  Can you please
double check?

jeff

Re: HOST_WIDE_INT = long long patch

[John Carr]

> I checked in a fix to synth_mult for multiplying by -1 on Apr 3.  In
> theory your patch shouldn't be necessary anymore.  Can you please
> double check?

That didn't fix the problem for me.  It turned out that my fix worked
because it masked a different error: certain operations were
incorrectly being assigned cost 0.  Use this patch instead.

Tue Apr  7 19:25:27 1998  John Carr  <jfc@mit.edu>

	* expmed.c (init_expmed): Initialize entire cost array when
	MAX_BITS_PER_WORD > BITS_PER_WORD.

diff -c -3 -p -r1.11 expmed.c
*** expmed.c	1998/04/04 17:37:49	1.11
--- expmed.c	1998/04/07 23:24:37
*************** init_expmed ()
*** 120,126 ****
    shift_cost[0] = 0;
    shiftadd_cost[0] = shiftsub_cost[0] = add_cost;
  
!   for (m = 1; m < BITS_PER_WORD; m++)
      {
        shift_cost[m] = shiftadd_cost[m] = shiftsub_cost[m] = 32000;
  
--- 120,126 ----
    shift_cost[0] = 0;
    shiftadd_cost[0] = shiftsub_cost[0] = add_cost;
  
!   for (m = 1; m < MAX_BITS_PER_WORD; m++)
      {
        shift_cost[m] = shiftadd_cost[m] = shiftsub_cost[m] = 32000;
  

Re: HOST_WIDE_INT = long long patch

[Jeffrey A Law]

  In message < 199804072327.TAA16420@jfc. >you write:
  > 
  > > I checked in a fix to synth_mult for multiplying by -1 on Apr 3.  In
  > > theory your patch shouldn't be necessary anymore.  Can you please
  > > double check?
  > 
  > That didn't fix the problem for me.
OK.  I couldn't ever convince myself that the change wasn't just
covering up the bug (the change is still correct, but it wasn't
clear if actually fixed the bug).  Anyways...

  > It turned out that my fix worked
  > because it masked a different error: certain operations were
  > incorrectly being assigned cost 0.  Use this patch instead.
Hmmm.  Seems to me like we shouldn't have been accessing elements
higher than BITS_PER_WORD in those arrays to start with.  That
might actually be the underlying bug.

It may or may not be relavent, but when I ran into this problem
last week it was on a machine with a nonvarying BITS_PER_WORD.

jeff

Re: HOST_WIDE_INT = long long patch

[Torbjorn Granlund]

Since I wrote this code, I am willing to fix it.  But it will have to wait
about one week, since I am busy at the moment.

Torbjorn

Re: HOST_WIDE_INT = long long patch

[Jeffrey A Law]

  In message < 199804081844.UAA02129@sophie.matematik.su.se >you write:
  > Since I wrote this code, I am willing to fix it.  But it will have to wait
  > about one week, since I am busy at the moment.
OK.  That's fine by me.

When you get the time to look into the problem can you peek at my
recent change.  I'm pretty sure it's a valid change, but if you could
double check it would be greatly appreciated.

Thanks!
jeff