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


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


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