This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: MEM_REF
> 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
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?