indirect_operand and memory_operand

[Zack Weinberg <zack at codesourcery dot com>]

Another concern related to the message I sent yesterday ("Drastic
simplifications to operand predicates") -- I'm wondering exactly what
the point of indirect_operand is.

The comment in recog.c is 

/* Return 1 if OP is a valid indirect memory reference with mode MODE;
   that is, a memory reference whose address is a general_operand.  */

So it sounds like it's intended to impose weaker requirements on an
operand than memory_operand does.  However, if you look at the code
you see, first, yet another incredibly weird thing having to do with
subregs before reload, and second

  return (MEM_P (op)
	  && memory_operand (op, mode)
	  && general_operand (XEXP (op, 0), Pmode));

So, after reload this predicate imposes requirements on its argument
which cannot possibly be weaker than memory_operand's requirements.

Instead, what it seems indirect_operand does is *restrict* the set of
valid operands compared to memory_operand.  If address_operand (per
weak GO_IF_LEGITIMATE_ADDRESS) allows forms of address expression
which are not general_operands, then MEMs with those address
expressions will be memory_operands but not indirect_operands.

I can imagine situations where this would be so, and where
distinguishing the two might be useful.  For instance, a complex
reg+reg+offset address might not be a general_operand, and there might
be instructions with limits on the addressing modes they accept.
However, general_operand takes just about anything, and further,
looking at the places where indirect_operand is actually used - there
aren't very many of them - it appears that they do not expect such
behavior.  The CRIS use, for instance, is specifically looking for
reg+reg+offset indexing.

So is there no point to indirect_operand?  Other than possibly the
aforementioned incredibly weird subreg thing?

zw