This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: indirect_operand and memory_operand


James E Wilson <wilson@specifixinc.com> writes:

> 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.

Thanks for the information.  Right now I am mainly looking to improve
the documentation of the generic predicates, as part of my patch-in-
progress to move target-specific predicates to the machine
description.  I'll add a note explaining this.  I might attempt to
remove the sole use from rs6000.md (which is the only target that uses
indirect_operand that I have access to) but I have lots of other
things on my plate right now.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]