On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
at the moment, any pass that needs to process memory references are
complicated (or restricted to handling just a limited set of cases) by
the need to interpret the quite complex representation of memory
references that we have in gimple. For example, there are about 1000 of
lines of quite convoluted code in tree-data-ref.c and about 500 lines in
tree-ssa-loop-ivopts.c dealing with parsing and analysing memory
references.
I would like to propose (and possibly also work on implementing) using a
more uniform representation, described in more details below. The
proposal is based on the previous discussions
(http://gcc.gnu.org/ml/gcc/2006-06/msg00295.html) and on what I learned
about the way memory references are represented in ICC.
It also subsumes the patches of Daniel to make p[i] (where p is pointer)
use ARRAY_REFs/MEM_REFs.
I am not sure whether someone does not already work on something
similar, e.g. with respect to LTO (where the mentioned discussion
started), or gimple-tuples branch?
I like the idea (though i haven't worked through I agree we want every
component you are describing). For the new value numberer, I actually
was value numbering component refs by effectively constructing a new
little IR (pool alloc'd) that was just a base and an array of all of
their offsets, types, etc, in order.
Basically something like what you are suggesting, but with only data i
cared about for value numbering.
From what I can tell did not use significantly more or less memory
than what we have now, but it was much easier to work with, IMHO.
Proposal:
For each memory reference, we remember the following information:
-- base of the reference
-- constant offset
-- vector of indices
-- type of the accessed location
-- original tree of the memory reference (or another summary of the
structure of the access, for aliasing purposes)
This i don't think we should keep, because i don't believe it's
necessary for aliasing. At worst, aliasing could come up with it's
own summary if it really wanted to.
-- 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.
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).
