This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: MEM_REF
- From: Richard Henderson <rth at redhat dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Diego Novillo <dnovillo at redhat dot com>, irar at il dot ibm dot com, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 May 2005 16:55:40 -0700
- Subject: Re: [PATCH]: MEM_REF
- References: <1116284725.8102.10.camel@linux.site> <20050516234159.GA14317@atrey.karlin.mff.cuni.cz>
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~