From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael P. Hayes" To: Joern Rennecke Cc: rth@cygnus.com, michaelh@ongaonga.chch.cri.nz, egcs@cygnus.com Subject: Re: Autoincrement addressing modes Date: Mon, 16 Mar 1998 20:44:00 -0000 Message-id: <199803162349.XAA24115@ongaonga.chch.cri.nz> References: <19980212023505.17080@dot.cygnus.com> <199803162251.WAA08886@phal.cygnus.co.uk> X-SW-Source: 1998-03/msg00561.html Joern Rennecke writes: > Adding a name is fine, but I wouldn't want to drop the mem. Note that the > mem has a mode, which is useful for a number of ports. > If it is not useful, you can still leave out the mode (i.e., it will be > VoidMODE). I think I like having the mem since it does indicate which modes are valid for the address (although it could be handled by an extra condition). If the mem was kept, this define_address construct could be generalised to something like define_operand which could detail all the valid operand forms for the target machine. I would also like to see a more generalised cost mechanism for operands that takes into account other operands used in an insn. For example, a small immediate integer may have a low cost in an insn if the other operand is a register, but a high cost if the other operand is a memory address. > moreover, we need some way to link the address forms to the places where > they are possible - e.g. it is common that the set of allowed addresses > for loads is different from the ones allowed for stores. The problem here is dealing with insns that may allow two addresses with small displacements but only one address with a large displacement. I suppose the only way to be sure that an address is valid for an insn is to try recognising the insn with that address. I've had similar problems (notably with instantiate_virtual_regs_1) where a small constant is added to an address. While the new address is deemed valid by memory_address_p, it is no longer valid for the insn it is used with.