Re: [PATCH] alias.c find_base_value fix

[David Edelsohn <dje at watson dot ibm dot com>]

	I'm still developing a patch to merge find_base_value() and
find_base_term() together.

	The main algorithmic difference between the two functions is how
they handle a REG.  find_base_value() returns the base or 0 (unknown base)
for both hard regs and pseudo regs.  find_base_term() returns the base for
hard regs during a "collecting" phase when it examines function arguments
and for pseudos if a base is known, otherwise it returns the hard reg or
pseudo itself.  find_base_term() never returns 0 (unknown base) for a REG,
but it does return the value for other cases.  find_base_term() has a
comment that returning the base for a hard reg can lead to endless
recursion, which seems plausible.

	Stopping at a hard reg makes sense, but returning a pseudo as a
base does not make sense to me.  That is what caused the problem for
20010430.f -- true_dependence believed that a pseudo and the frame pointer
could not conflict.  If we trace back to a pseudo, we either do not have
any information or the pseudo was created out of whole cloth and could
reference anything.

	I am going to try a merged version of the two functions which
returns 0 for pseudos about which no information is known and stops at
hard regs if not collecting.  If it does not cause any regressions, I am
going to ask people to run some benchmark comparisons to see what this
change does to code generation.

	The algorithm seems more accurate, but this could cause some
performance hits if GCC was playing fast and loose before by thinking that
bases which were pseudos could not conflict.  If there is a performance
hit, then it becomes a question of how and when to fix this latent bug.

David