This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: merging MEM_ATTRS


    Funny, the references links work just fine for me.

The links worked: I just didn't see a relevant discussion there.

    A lot of MEM_EXPRs from pointer dereferences are zero right from RTL
    generation, while for all explicit references of a variable, we have a
    proper MEM_EXPR describing just that varaible.

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.

    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
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.

    I.e. a zero MEM_EXPR means that we don't know anything of the access
    except that it can't be for any specific variable which didn't have
    its address taken.

No, it means we know nothing about what variable it might reference.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]