Re: [PATCH]: MEM_REF

[Richard Henderson <rth at redhat dot com>]

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.

> Of course we can use TARGET_MEM_REFs before ivopts without these
> invariants and fields limited to base, index and a fixed step, and
> switch to the new set of invariants after ivopts.

Yes.

> However this approach has several drawbacks; in particular we would
> need to lower all the 'old' TARGET_MEM_REFs to the new semantics ...

Yes.

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

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

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


r~