Re: A new linux/alpha failure (aliasing bug)

[Jim Wilson <wilson at chestnut dot cygnus dot com>]

This is due to a bad interaction between the new alias analysis code and
the way that the alpha port works.  The testcase is aliasing a char * and
a long *.  The ANSI C standard allows this.  The way that the new (and old)
aliasing code handled this was to assume that a QImode MEM could alias
anything.  Unfortunately, the alpha (pre ev5 or whatever) does not have char
loads/stores.  So instead of emitting a QImode MEM, it emits a DImode MEM
and then does an extract/insert to get a byte load/store.  Since there
is no QImode MEM, we miss the fact that there is aliasing.  The old code
has the same flaw, but it reports false aliasing so often that we apparently
never noticed the problem.

It appears that we need some way to tell that some non-QImode load/stores
are really char * load/stores.

One possibility is to assume that an AND operator in an address implies
a char * access.  On an Alpha, any QImode/HImode reference will use an
address of the form (mem/s:DI (and:DI (reg:DI 76) (const_int -8))).
The a29k port does the same thing for QImode references if byte operations
are disabled.  Offhand, I do not know of any other port that allows AND in
an address or that is missing byte loads.  This change would solve the problem
at the expense of adding some false aliases for HImode references on the
alpha.  This change should not require any md file changes though.

Other possibilities are to require that patterns that perform a char *
access must have a QImode mem in them or add a special REG_NOTE to indicate
that we have a QImode reference.  However, both of these have the risk that
the optimizer may lose the aliasing info, because it is not directly connected
to the MEM itself.  Safe schemes seem to require that we rely on info that
is inside the MEM itself.

Suggestions welcome.

Jim