indirect_operand and memory_operand

[James E Wilson]

Zack Weinberg wrote:
> Instead, what it seems indirect_operand does is *restrict* the set of
> valid operands compared to memory_operand.

Yes.  This is pretty obvious if you look at gcc history. 
indirect_operand is present in gcc-1.42, and the only place where it is 
used is for the i386 port as the first operand of call, i.e. the call 
address.  Here it is pretty clear that we are restricting addresses to 
be valid operands themselves, to avoid things like reg+reg addresses as 
call addresses.  However, this construct could just as easily be handled 
by using something like
    (mem:SI (match_operand:SI "general_operand" 0))
and in fact the current i386.md file does do something like this.

So there appears to be no use for this predicate.

The uses that have appeared since then look like they can all be fixed.

The v850.md file just wants an offsettable address, which we can get 
with the o constraint, and optionally a predicate to accept only mems 
with offsettable addresses might be useful here.

The cris.md file looks like another (mem (... general_operand)) case. 
However, it is not looking for reg+reg+offset as you suggested.  You 
misread the comments.  cris has memory-indirect addresses, e.g. (mem 
(mem (reg)).  The pattern here is looking for either a constant address, 
or a memory-indirect auto-inc address, or a memory-indirect address. 
That is what the comment
   ;; where indirect ref = {const, [r+], [r]}
means.  See also the condition which explicitly accepts only addresses 
that are constants or MEMs.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com