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. 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. All in all, I believe it will need some experimentation, but we should not consume more memory than we do now, and possibly we could even save somewhat. Zdenek
