This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Nov 27, 2008 at 2:22 PM, Luis Machado
<luisgpm@linux.vnet.ibm.com> wrote:
> Hi,
>
> The attached patch changes the handling of LO_SUM in "find_base_term" to
> what "find_base_value" does.
>
> No additional testsuite failures were noticed and SPEC2K numbers are
> stable. Vortex 32-bit (that had degraded due to this problem) is back to
> normal (up 3%) on PPC.
>
> OK for mainline?

Ok.

Thanks,
Richard.

> Thanks,
> 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
>>
>
> 2008-11-27  Luis Machado  <luisgpm@br.ibm.com>
>
>        * alias.c (find_base_term): Synch LO_SUM handling with what
>        find_base_value does.
>
> Index: gcc/alias.c
> ===================================================================
> --- gcc.orig/alias.c    2008-11-25 19:43:01.000000000 -0800
> +++ gcc/alias.c 2008-11-27 04:54:09.000000000 -0800
> @@ -1408,6 +1408,9 @@
>        return 0;
>       /* Fall through.  */
>     case LO_SUM:
> +      /* The standard form is (lo_sum reg sym) so look only at the
> +         second operand.  */
> +      return find_base_term (XEXP (x, 1));
>     case PLUS:
>     case MINUS:
>       {
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]