On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
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
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> 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 kee
Hello,
> >Remarks:
> >-- it would be guaranteed that the indices of each memory reference are
> > independent, i.e., that &ref[idx1][idx2] == &ref[idx1'][idx2'] only
> > if idx1 == idx1' and idx2 = idx2'; this is important for dependency
> > analysis (and for this reason we also need to reme
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
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> 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 o
Zdenek Dvorak wrote:
Sorry, but you are completely out here. I have spent a lot of time
working with the code for dealing with memory references, trying many
different approaches.
[ to put a different spin on it ]
It just might be that most of Roger Sayle's Fortran front end
optimizations -
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
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
>
On Wed, Apr 04, 2007 at 09:27:12PM +0200, Zdenek Dvorak wrote:
> 3) making this offset into an index, i.e, having
>base: &a, indices: (step:1, value: n)
>
> Out of these, I like 3) the most, although it might be fairly expensive
> memory-wise (any idea how common the variable offsets are?)
Hm
Hello,
> > -- 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)
> > -- flags
>
> What do you do with Ada COMPO
> What do you do with Ada COMPONENT_REFs, at a variable offset?
You can certainly get COMPONENT_REFs with variable offsets in GNU C,
but I'm familiar enough with the VLA stuff in the standard to know if
it can occur in standard C.
It's poorly implemented, unrefactored, without formal specification,
without OO hierarchy, etc.
"The pointers are the evilness of the optimization".
On Wed, Apr 04, 2007 at 04:35:08PM +0200, Zdenek Dvorak wrote:
> 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 summ
On 4/4/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
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 compl
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> 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 kee
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
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
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> >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 ref
Hello,
> >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 o
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
On 4/4/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
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 compl
Hello,
> >> This looks like a very complicated (though very generic) way of
> >> specifying a memory
> >> reference. Last time we discussed this I proposed to just have BASE,
> >OFFSET
> >> and accessed TYPE (and an alias tag of the memory reference). I realize
> >> this
> >> doesn't cover acce
On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I rea
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
Hello,
> This looks like a very complicated (though very generic) way of
> specifying a memory
> reference. Last time we discussed this I proposed to just have BASE, OFFSET
> and accessed TYPE (and an alias tag of the memory reference). I realize
> this
> doesn't cover accesses to multi-dimensi
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
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
27 matches
Mail list logo
