Fix IA-64 bootstrap failure

Jan Hubicka
Fri Jan 30 13:57:00 GMT 2004

> On Thu, 2004-01-29 at 02:18, Jan Hubicka wrote:
> > Since you went trought the fixing the issue too, can you please try to
> > verify my reasioning in the mail?  I am not at all sure about it, but it
> > seems to make sense to me.
> I've been thinking about this a bit.
> Suppose we have an address (reg 100) which holds the value (plus (fp)
> (reg 200)).  Suppose also we have an address (reg 101) which holds the
> value (plus (symbol_ref) (reg 201)).  We get cselib values for both
> addresses.  Then registers 200 and 201 are modified, invalidating the
> cselib values.  Then we try to do alias analysis.  If we have two
> invalid cselib values, then we can do nothing at all.  If we have the
> original rtx, then we can see that the two addresses can not alias,
> because one is a stack address and one is a heap address.  It doesn't
> matter that we don't have values for regs 200 and 201.  We don't need
> them.  This seems to be a case where invalidating cselib values loses
> out.  However, I haven't tried going through the cselib/sched/alias
> logic to see if this case can actually happen.

I think I didn't changed this behaviour, so if it happent, it happent
before my patch too.
One important thing to take into account is that schedule-ebbs runs only
after reload, so registers are commonly reused and alias analysis based
on discovering registers assigned to fixed value are not terribly
usefull.  I am not even sure it can notice that values on frame don't
overlap with symbol, as it will simply lose track.

The machinery will work as follows:
Cselib will rewrite (plus (fp) (reg 200)) into
(plus (fp) (value X)) and later use of (plus (fp) (value X)) into
(value Y)
So information is not lost until CSElib invalidate all values value X is
stored/computed in.
Then value X will get discarded that will in turn cause value Y to be
discarded too and we lose that information.

It may be worthwhile to experiment with disabling the discarding code
when called from scheduler and see if it brings measurable benefits for
IA-64.  (with the memory reduction patches it may not be that
disasterous thing to do)  Still i think for 3.4/3.5 we can go with fixed
version of my patch as attached.


2004-01-28  Jan Hubicka  <>
	* alias.c (find_base_term, get_addr):  Do not dereference NULL
	pointer when all VALUE's locations has been invalidated.
	(rtx_equal_for_memref_p): Simplify.
Index: alias.c
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.212
diff -c -3 -p -r1.212 alias.c
*** alias.c	22 Jan 2004 11:35:58 -0000	1.212
--- alias.c	30 Jan 2004 13:47:08 -0000
*************** rtx_equal_for_memref_p (rtx x, rtx y)
*** 1139,1147 ****
    /* Some RTL can be compared without a recursive examination.  */
    switch (code)
-     case VALUE:
-       return CSELIB_VAL_PTR (x) == CSELIB_VAL_PTR (y);
      case REG:
        return REGNO (x) == REGNO (y);
--- 1139,1144 ----
*************** find_base_term (rtx x)
*** 1325,1330 ****
--- 1322,1329 ----
      case VALUE:
        val = CSELIB_VAL_PTR (x);
+       if (!val)
+ 	return 0;
        for (l = val->locs; l; l = l->next)
  	if ((x = find_base_term (l->loc)) != 0)
  	  return x;
*************** get_addr (rtx x)
*** 1502,1515 ****
    if (GET_CODE (x) != VALUE)
      return x;
    v = CSELIB_VAL_PTR (x);
!   for (l = v->locs; l; l = l->next)
!     if (CONSTANT_P (l->loc))
!       return l->loc;
!   for (l = v->locs; l; l = l->next)
!     if (GET_CODE (l->loc) != REG && GET_CODE (l->loc) != MEM)
!       return l->loc;
!   if (v->locs)
!     return v->locs->loc;
    return x;
--- 1501,1517 ----
    if (GET_CODE (x) != VALUE)
      return x;
    v = CSELIB_VAL_PTR (x);
!   if (v)
!     {
!       for (l = v->locs; l; l = l->next)
! 	if (CONSTANT_P (l->loc))
! 	  return l->loc;
!       for (l = v->locs; l; l = l->next)
! 	if (GET_CODE (l->loc) != REG && GET_CODE (l->loc) != MEM)
! 	  return l->loc;
!       if (v->locs)
! 	return v->locs->loc;
!     }
    return x;

More information about the Gcc-patches mailing list