[PATCH]: MEM_REF

[Daniel Berlin]

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

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.

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.

Again, i'm not saying these are insurmountable problems, AFAIK.
It's just that i gave up after about 6 hours  of fighting them and
decided MEM_REF was better, because they seemed to have different enough
uses, and to be honest, i was tired of fighting :)

If you guys are telling me you don't believe this, i'm willing to go
take a few more whacks at ARRAY_REF and post about whatever explicit
problems i have.

> 
> Zdenek