[Bug target/10021] [3.3/3.4 regression] [m68k] alias problem during loop pass
wilson at gcc dot gnu dot org
gcc-bugzilla@gcc.gnu.org
Mon Jun 30 08:18:00 GMT 2003
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10021
------- Additional Comments From wilson at gcc dot gnu dot org 2003-06-30 08:18 -------
true_dependence fails when its arguments are (mem (plus sp -64)) and (mem (reg
1143)). The failure happens in base_alias_check. The base of the first is
ADDRESS sp, and the base of the second is REG 1143. Since one has a base in the
stack and the other don't, we indicate that they don't alias. The problem here
is that reg_base_value should never be a register. The comments say it can only
be a ADDRESS, SYMBOL_REF, or LABEL_REF. This takes us to find_base_value, which
when given a reg with no known base_value, it returns the reg. This contradicts
the comments at the top of the file. Returning 0 for a unknown reg instead of
itself seems to be the correct solution. I haven't looked into this very
closely as yet though.
While looking at this, I also noticed that ARRAY_REFs were resulting in MEMs
that did not have the MEM_IN_STRUCT_P bit set. The problem here is in
set_mem_attribute_minus_bitpos. It has code at the end to check to see if the
argument t is an ARRAY_REF. Unfortunately, in the middle, it has a loop that
modifies the argument t. This can be fixed by creating a temporary t2.
The resulting patch seems to solve this testcase, since there is no longer any
load hoisting. However, I haven't checked to see if this is disabling too much
optimization yet.
I will put the patch in an attachment.
Jim
More information about the Gcc-bugs
mailing list