Re: (define_address ...) suggestions needed

[Denis Chertykov <denisc at overta dot ru>]

Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

> Some machines support nested MEMs, so this has to be supported in some way.
> 
> What might be useful is to specify a constraint letter for every addressing
> mode.  GCC currently has a few hardcoded ones ('<', '>', 'm', 'o',
> ...); it

IMHO after (define_address ...) will be fully supported only one
constraint 'm' will be needed. See below.

> would be nice if every pattern could specify exactly what kind of addresses
> it can accept in an operand.

> This might solve a problem we have on the Thumb
> where different insns accept different base register classes when loading
> from memory.

IMHO this is a two different things (one true BASE_REG_CLASS and
insn pattern - address patterns link).

My second step will be substitute BASE_REG_CLASS to something like

enum reg_class
BASE_REG_CLASS_FOR_ADDRESS (ADDRESS)
	rtx ADDRESS;
{
  int icode;

  icode = recog_address (ADDRESS);
  extract_address (ADDRESS, icode);
  return REG_CLASS_FROM_LETTER (*insn_data[icode].operand[0].constraint);
}

Also I'm already thinking about linking (define_address ...) patterns
by names to lists for using it as predicates in (define_insn ...)'s.

This is a real possibility to avoid any memory constraints except 'm'.


(define_predicate "memory_thumb_cmd_source_operand"
  ["base","reg","immediate"] ;; (define_address ...) names
  ["register_operand", "immediate_operand"]  ;; other existing predicates
)

(define_predicate "memory_thumb_cmd_destination_operand"
  ["base","reg"]
  ["register_operand"])

What you think ?

Denis.