This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: MEM_REF


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?

> 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)?

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

no, of course I understand you did not decide to just create a new tree
node without having some reasons for it.  But if we are going to do
hacks like sharing the MEM_REFs and TARGET_MEM_REFs that most definitely
is going to lead to load of problems, we should have very good reasons
for it, IMHO.

Zdenek

> , i'm willing to go
> take a few more whacks at ARRAY_REF and post about whatever explicit
> problems i have.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]