Re: RFC: merging MEM_ATTRS

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

> 
>     that means when we have a pointer dereference or array access, instead
>     of punting and putting NULL_TREE there, we can use a special marker
>     tree there (preferrably a shared one) that says that some indirection
>     is involved at source-code level, and hence this can't mean any
>     variable that didn't have its address taken.
> 
> That's not the case for an array acess per se since that references the
> array variable.

Oops, I was thinking too much in C language family terms when I spoke
about array references.  Altough there is syntax for array references
in C, we actually end up with an addressable array and a pointer
dereference.  (Of course we could make the compiler disregard this
'address taking' from the array decaying to a pointer for optimization
 purposes from pointer decaying when we find we have actually just a
 plain array reference... but I'm not actually concerned about this
 at the moment.)
I suppose that's different in other languages, where you can actually
use arrays without taking their address.

>                  I think it's just the case for a dereference and there's
> certainly no problem with something like an INDIRECT_REF of an ERROR_MARK
> or some such.  In that case, merging two different MEM_EXPRs to zero would
> lose information, but I suspect the loss would be trivial in practice.

The nice thing here is that we can merge it to zero for now, but change
this to a tree_vec when we find this to be useful.  I see no scalable way
to extend the alias set approach in that direction.

Let's see what the special node could be.  re-using error_mark_node itself
would be cheapest, but would be quite confusing, as there is no actual
error involved.
An INDIRECT_REF of NULL_TREE would be consistent with what we currently
have, in being an indirection of something we can't or don't want to
specify further.
But if there is a problem with having the NULL_TREE inside there, putting
an error_mark_node inside would also be fine with me.  We'll still have
a special dedicated node with it's own variable name
(unspecified_indirect_ref_node ? ) which will get its own comment,
and we can compare it for pointer-equality.