This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX
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
>