RFC: merging MEM_ATTRS

[Joern Rennecke <joern dot rennecke at superh dot com>]

cross-jumping and if-conversion sometimes want to merge two equal
instructions that contain a MEM into one.  The equality sometimes
does not extend to the memory attributes.
I think completely prohibiting merging of MEMs because they have different
attributes goes a bit to far.  But we want to be able to tell if a given
MEM might access a particular static variable, and also to make alias
analysis safe.
I think it is best that we require that when such a mergeing takes place,
the resulting MEM_ATTRS indicates that the actual memory access could
be any of a number of alternatives.  A merge where we loose information,
or that merges qualitatively different things, is considered more costly
because it could prevent subsequent optimizations.  Depending on
how much cycles (-O2) or instructions (-Os) the merging will safe,
we might still go ahead with such a merge if our heuristics say that
the benefits seem to outweigh the cost.

The struct mem_attrs we have right now doesn't lend itself easily to
express these alternatives.  We could extend it, but then we'd have
to pay a memory cost even if no mergeing takes place.

So I was thinking of representing the alternatives in the individual fields:

alias set: Use an alias set that contains the union of the alias sets
 involved.  I.e. two identical alias sets merge to itself, while most
 or all incompatible ones probably merge to the 0 alias set - in that
 case the merging is considered a bit more costly, because we loose
 some more information.

expr: If all alternatives are identical, use that, otherwise use a PARALLEL.
offset: Likewise.
size: All alternatives must match.
align: uses the lowest common denominator.  Lowering the alignment of
 one or more of the alternatives is considered to incur a cost, although
 probably not a large one when we've selected structurally identically
 instructions in the first place.