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,

> On Tue, May 17, 2005 at 01:42:01AM +0200, Zdenek Dvorak wrote:
> > The purposes of the nodes are really quite different, and
> > TARGET_MEM_REFs as implemented now satisfy some invariants useful
> > mostly in the very late tree optimizations.  In particular
> > TARGET_MEM_REF is never nested with other memory reference nodes (like
> > COMPONENT_REFs or ARRAY_REFs) -- it just represents the flat access to
> > memory, mapping directly to MEM node on rtl.
> 
> I don't recall if Diego got around to mentioning this, but I think
> that the lack of COMPONENT_REFs in TARGET_MEM_REF means problems 
> for the alias analysis.  I'd been thinking that the slot you use for
> the DECL should be extended to any base-ref-able thing.

what problems, exactly?  The old reference is still stored (TMR_ORIGINAL
field), thus you still see the structure of the reference in case alias
analysis needs it (which the RTL level one does).  At the point
TARGET_MEM_REFs are created, we should not want to run another tree
level alias analysis pass -- once we decided to lower the address arithmetics,
we are of course losing some of the information (or at least making
it harder to access); we should just use the information we gathered
before (which we do by storing TMR_TAG).

> > (unlike the current approach
> > where I rewrite only those memory references for that ivopts find it
> > useful).
> 
> Don't you think that's likely to be the case for most array-like
> things in loops?

yes.  But if we decide to change the semantics of TARGET_MEM_REFs at
that point, we must change them all -- i.e. not just in loops.

> > One possible way would be to rewrite all the memory references to
> > TARGET_MEM_REFs at that point (which I would like to do anyway) ...
> 
> It's definitely worth experimenting with.
> 
> > The problems of course are not unsurmountable.  However having the
> > separate nodes would IMHO be much cleaner -- the purposes are quite
> > different, and changing the semantics of the node in the middle of
> > compilation seems somewhat hacky to me.
> 
> This differs from any of the other IL lowering we do in what way?

Not too significantly; it however uses one tree node for two quite
different purposes, which is somewhat confusing.

> > What are the reasons for doing so?
> 
> We've currently got 4 nodes that reference memory; you're considering
> adding two more.  Don't you think that proliferation is confusing?
> I do.

I consider it even more confusing to use one tree node for two purposes.
I prefer more tree nodes, as long as they have a clear semantics and
purpose.

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.  Daniel, could you please explain more precisely why you
did not chose this way?

Zdenek


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