Re: Fix IA-64 bootstrap failure

[Jim Wilson <wilson at specifixinc dot com>]

Jan Hubicka wrote:
> 	* alias.c (find_base_term, get_addr):  Do not dereference NULL
> 	pointer when all VALUE's locations has been invalidated.

This patch looks like the right idea.  If CSELIB_VAL_PTR is NULL, then 
we have no alias info at all.

I believe you missed one place that needs to be fixed.  Just searching 
for CSELIB_VAL_PTR, I see code in rtx_equal_for_memref_p
    case VALUE:
      return CSELIB_VAL_PTR (x) == CSELIB_VAL_PTR (y);
which is now wrong if CSELIB_VAL_PTR can be zero, since two zero valued 
pointers are not equal here.  We need a != 0 check here for one of the 
pointers, and then I think this patch is right.

However, I haven't seen anyone yet question whether it is wise for the 
scheduler to even be using cselib in the first place.  When 
CSELIB_VAL_PTR is zero, we have no alias info at all.  In this case, we 
would have been better off if hadn't called cselib at all, as then we 
would have the original rtx, and we might bave been able to do something 
with it.  There needs to be some thought given to this path we are going 
down, as we are slowly losing the ability to do alias analysis in the 
scheduler.  Maybe we shouldn't be using cselib in the scheduler, or 
maybe cselib should be maintaining values while the scheduler still 
needs them, or maybe we should have a way to get the original rtx back 
when a cselib value disappears.   We still have the MEM_EXPR values, is 
that maybe good enough when a cselib value disappears?
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com