This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal: changing representation of memory references
On 4/4/07, Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote:
Hello,
> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also keeping it in the references.
> >
> >The lower bound and step may be SSA_NAMEs, see the current ARRAY_REF,
> >and as such, they need to be stored somewhere in IR (not just in type).
> >
> >> That is, unless we could share most of the index struct (upper,
> >> lower, step) among expressions that access them (IE make index be
> >> immutable, and require unsharing and resharing if you want to modify
> >> the expression).
> >
> >That appears a bit dangerous to me, I would rather avoid such tricks.
>
> Like Richard, I have doubts you are not going to increase memory if
> you store *this* much in every single memory access.
for structured accesses (ARRAY_REFs etc.) we now need much more memory --
4 pointers, plus overhead of the common tree fields. My proposal will
save some memory here.
I'm not sure how, since you have more than 4 pointers worth of info in:
-- base of the reference -> pointer
-- constant offset -> HOST_WIDE_INT
-- vector of indices -> embedded vec
-- type of the accessed location -> Pointer
-- original tree of the memory reference (or another summary of the
structure of the access, for aliasing purposes) -> pointer
-- flags -> No idea
for each index, we remeber
-- lower and upper bound -> pointers
-- step -> pointer
-- value of the index -> pointer
What have i misunderstood?
On unstructured accesses (INDIRECT_REFs), the proposal would indeed
require three extra pointers. I now think keeping INDIRECT_REFs might
turn out to be necessary, to represent unstructured memory accesses.
Having to deal with INDIRECT_REFs should not complicate optimizers
significantly, so it would not beat the purpose of the patch.
I think it would, if the purpose is to have a unified way to represent
memory accesses that is usable by both optimizers and data dependence.
IMHO Base + offset is probably enough, based on the problems i've seen
in the past (not being able to figure out offset because of compiler
generated casts, etc).