Re: Another case of DCE deleting live code

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

    *shrug* Maybe, maybe not.  Depends on how you think about it.
    Alternately, it's a normal pointer to a type that's aliased.

    I mentioned to Diego in private mail that I thought that this
    flag could be dropped entirely in favor of the creation of a
    new type node that uses alias set zero.  Something like

	aliasing_type = build_distinct_type_copy (type);
	TYPE_ALIAS_SET (aliasing_type) = 0;

    Or something.  I kinda doubt it would work to use a variant
    type copy; too many things want to remove that cast.

Hmm... Interesting set of tradeoffs.

The motivation for this is the Ada case where you have an unchecked conversion
between two pointers and the things they point to have different alias sets.
In that case, you want to say that the pointer can dereference anything.

But the object, once dereferenced, is of the normal type.  So right now,
we have an INDIRECT_REF whose result is the normal type but the pointer
has TYPE_REF_CAN_ALIAS_ALL.

The alternative is indeed a regular pointer, but to a "variant" of the
type that has alias set zero.  When you do that, though, you need a
VIEW_CONVERT_EXPR to make the tree type-correct (at least in GENERIC,
there's an ongoing discussion about in GIMPLE).

I think it's actually fine to make this a variant because it's fine to remove
the conversion: the only thing we really care about the alias set of is the
INDIRECT_REF.  So I'd suggest a TYPE_QUAL_ALIAS, which says to force the type
to the alias set specified in TYPE_ALIAS_SET (so it's a little different than
other qualifiers), but I'd also be OK with TYPE_QUAL_ALIAS0.

Indeed I think this is a cleaner implementation and I'm perfectly willing to
make this change.  I think it's fine for Stage3 because only Ada uses this
flag currently.

Should I do this?  I do have a test case for this, though finding it may
be tricky.