Re: Proposal: changing representation of memory references

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

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

consider a[i][j], on 32 bit machine:

Currently, this is two ARRAY_REFS, 40 bytes each, for total of 80 bytes.
With my proposal, this would be 24 bytes (the items contained in the
base of tree_exp: tree_common, including type+flags; locus, and block),
base, offset, summary, vector (16 bytes), in the vector size and bound
(8 bytes), plus 2 indices (16 bytes each), for total of 80 bytes.

I.e., we get the same memory consumption for references with at least
two levels.  For each other index or component ref, the proposed
representation saves 40 - 16 = 24 bytes.

There are some possible improvements:
-- if we used tail array for the indices instead of vector, we could
   save some 8 bytes
-- assuming that the case that the bounds or step of the array are
   varying is infrequent, we can change the representation to require
   -- 8 bytes/index if both bounds and the step are constants,
   -- ~32 bytes otherwise
   by refering to the appropriate array type in the former case
   and TREE_VEC containing the three values in the latter case,
   or some similar representation

Zdenek