Re: [PATCH]: MEM_REF

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > I tried (In fact, this was my goal before MEM_REF came about), but he
> > has incredibly different goals, and wants a 5 operand tree that the
> > optimizers don't touch once generated, not something generated by the
> > front end.
> > 
> > IE he wants something that is there right before expansion so he can do
> > address selection.  Thus, his tree has to match addressing modes of most
> > processors, which is why it has 5 operands.   Using a 5 operand tree for
> > MEM_REF would be somewhat ridiculous and defeat the whole purpose of a
> > simple array like operation.
> > 
> > 
> > In fact MEM_REF was started after an email discussion with Zdenek where
> > it became clear that our goals were significantly different so that one
> > tree would not server both purposes.
> > 
> > 
> > 
> > 
> 
> After some discussion, the current plan looks like this:
> 
> Have TARGET_MEM_REF with however many operands, but require some of the
> the operands be fixed before ivopts (or whatever is going to do
> addressing mode selection).  This situation will be verified using a
> verified.
> IE it's "lowered" by ivopts (or whatever), so that all operands can be
> used freely.
> 
> However, before then, it still looks like a nice array reference that we
> can do dependence analysis on without much trouble.
> 
> Zdenek, is this okay with you?

I assume you allow representing things like p[i].x as
COMPONENT_REF (MEM_REF (p, i), x)?  If so, I would somewhat prefer having
MEM_REF (ugh .. perhaps with a different name) and TARGET_MEM_REF as separate
tree nodes.

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.

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.  However this approach
has several drawbacks; in particular we would need to lower all the
'old' TARGET_MEM_REFs to the new semantics (unlike the current approach
where I rewrite only those memory references for that ivopts find it
useful).  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), but I am not
sure whether loop optimizations are not too soon for this and whether
we should not keep an option of doing this later in the compilation.

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.  What are the reasons for doing
so?

Zdenek

> If so, the parts we probably want to merge are the c-typeck.c stuff, and
> maybe the lowering stuff (it depends on whether you think it is better
> to lower mem_ref directly, or regenerate your info from INDIRECT_REF's,
> i have no idea).
> 
> I'll write a verification pass that is used before ivopts that makes
> sure the operands we want fixed stay fixed (in particular, offset will
> be fixed 0, and step will be fixed at the size of the pointed to type).