RFC: merging MEM_ATTRS

Joern Rennecke joern.rennecke@superh.com
Tue Feb 10 19:34:00 GMT 2004


> Wrong.  We *may* have such a MEM_EXPR if we know we're referencing that
> variable.  There's no guarantee such will exist.  If we have a MEM with
> a zero MEM_EXPR, it may reference *any* variable in its alias set.

With the way the rtl generators work, the MEM_EXPR is guaranteed to be
created for a plain variable reference - and we can have only those
if the address was not taken.

>     The optimization I am trying to add recognizes a class of variables
>     where all references are explicit, and then 'knows' that MEMs that
>     reference such variables can't alias MEMs that don't reference them.
> 
> The only way to do that is via a different alias set, perhaps by creating

The only way it can be done?  Certainly not.
Do you mean the only way you think it should be done?

> a subset alias set for a type that we use when we know nothing takes the
> address of that variable.  I was thinking of doing this in Ada because
> the language says which variables may or not may have their address taken,
> but never worked out all the details.

But that soon leads to a combinatorial explosion when you have thirty such
variables...  most of the time, you'll want the set that contains none
of these variables, sometimes you'll want to include one or more likely
two of them, but conceptually we could have many of them.

Maybe a combination of the two concepts would work best: one alias set
per type which means: doesn't reference anything that isn't mentioned in
the MEM_EXPR.



More information about the Gcc mailing list