Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX

[Luis Machado <luisgpm@linux.vnet.ibm.com>]

Hi,

Both approaches fix the regression on vortex with no noticeable
performance degradations on 32-bit. I'll check the numbers for 64-bit to
make sure we're OK there as well. I'll also check the testsuite results
with both approaches.

Regards,
Luis


On Thu, 2008-11-06 at 16:16 -0700, Jeff Law wrote:
> David Edelsohn wrote:
> >
> >   
> >>> find_base_term() either could check for non-zero base before returning
> >>> in the lo_sum/plus/minus case statement or could handle lo_sum
> >>> explicitly, like find_base_value().
> >>>       
> >> I think my suggestion will accomplish the same thing -- and it makes logical
> >> sense too -- if we can't determine something from the pointer reg, then we
> >> look at other info, such as the symbol_ref within a lo_sum.
> >>     
> >
> > Yes, it will accomplish the same thing for this particular case.
> >
> > Currently find_base_value and find_base_term differ in their handling
> > of LO_SUM.  My question is whether this fix should maintain the difference
> > in algorithms. 
> I suspect the differences are unintentional and  one could easily argue 
> that find_base_value's handling of LO_SUM is better since LO_SUM has 
> pretty well defined semantics.  One could also argue that both functions 
> shouldn't be so eager to return the results of the recursive call when 
> the recursive call returns NULL.
> 
> >  Also, RTL alias analysis is very fragile and your suggestion
> > may produce more accurate information in other situations, which could
> > expose other latent bugs or unexpected behavior.
> >   
> Part of the intent was to get the more accurate info in the presence of 
> registers marked with REG_POINTER.  While it could expose latent bugs, I 
> think it's the right thing to do -- though we might look for a change 
> with a smaller impact for the upcoming release since I think we're in 
> stage3.
> 
> jeff
>