[PATCH]: MEM_REF

[Daniel Berlin]

On Tue, 2005-05-17 at 03:10 +0200, Zdenek Dvorak wrote:
> Hello,
> 
> > > If anything, it would seem more natural using ARRAY_REFs for the purpose of
> > > MEM_REFs -- their semantics is much, much closer than the one of
> > > TARGET_MEM_REFs.  I know Daniel tried this and run into problems
> > > (too many places where we have assumptions on types of operands of
> > > ARRAY_REFs, or something like that), but (without really investigating
> > > the problem) I would be inclined to believe that adding handling
> > > of MEM_REFs everywhere where needed or adding handling of ARRAY_REFs
> > > whose base is a pointer on these places should have about the same
> > > difficulty. 
> > You'd be quite wrong.
> > As my patch for MEM_REF showed, there are *very* few places that you
> > have to modify to add MEM_REF.
> > 
> > I dare you to put a POINTER_TYPE in first argument ARRAY_REF and start
> > counting the number of places you get failures :).
> > 
> > >  Daniel, could you please explain more precisely why you
> > > did not chose this way?
> > 
> > 1. Things expect the underlying array in the array_ref to have a size
> > associated with it that gives an upper bound, variable or not.  Lots of
> > things depend on this being there.  They also depend on being able to
> > find the upper bound by multiplying one by the other.
> > The array-like pointer accesses of course, have no easily determinable
> > upper bound or fixed size thing in there to use.
> 
> however, this should not be that much different from the case when we
> have array without size as a parameter of a function?

Decayed to a pointer.

> 
> > 2. expand and the stack assigner were getting mightily pissed that we
> > had a non-aggregate in the array_ref.  I can try this again if you want
> > exact details on what was going wrong.
> 
> The simple (although a bit memory-wasty) solution would be to just do
> not allow expand to ever see such ARRAY_REFs, i.e. to just decompose
> them to INDIRECT_REFs (just before expand or preferably even within
> expand_expr)?

I could do this.

> 
> > 3. We will have to do different things to the array_ref anyway in some
> > cases anyway depending on whether the first argument is an array or a
> > pointer.
> 
> Definitely.  This is the part I would fear the most -- catching all the
> places where some such change is needed would be problematic and we
> might introduce hard to find latent bugs.

Again, i'l lgive it some more work and see what it looks like :)