[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