This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: MEM_REF
> 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
IE it's "lowered" by ivopts (or whatever), so that all operands can be
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?
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).