Re: RFC: merging MEM_ATTRS

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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.

Agreed.

    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.

And I also don't think we need that level of detail.

    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.

Right.  But you also have the case where one is a subset of the other.  In
which case you can use the superset.

    expr: If all alternatives are identical, use that, otherwise use a
	PARALLEL.
    offset: Likewise.

I think that it's simpler just to use zero: the information isn't that useful
by then.

    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.

They are powers of two, so just use the lowest.  But since we don't
really use the alignment of a MEM that's already in an insn, I don't
see the cost here.