This is the mail archive of the
mailing list for the GCC project.
Re: Question about movM insn restrictions
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: marekm at amelek dot gda dot pl, gcc at gcc dot gnu dot org, Richard dot Earnshaw at arm dot com
- Date: Fri, 10 May 2002 18:41:27 +0100
- Subject: Re: Question about movM insn restrictions
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > But I can't find this restriction in the manual - does it still
> > exist?
> Yes. In the overview, "For the generate pass, only the names of the
> insns matter, . . . without regard for the RTL template or operand
> constraints. Note that the names the compiler looks for are hard-coded
> in the compiler . . ."
> In the movM description, it says that these patterns will be used for
> many things. Since it's invoked by name, there's no opportunity for
> predicates or constraints to even apply until later.
> > I ask because in the AVR port, there are so many alternatives to
> > handle and it would be easier to read if the move insns were split
> > into a few smaller unnamed insns, each handling only some of the
> > possible operands.
> Use a define_expand for movM and have it expand into the appropriate
> specific pattern(s). Once it's expanded by name, you can use as few
> or as many patterns as you like, as long as they're unambiguously
> matchable. Note that you must use predicates to do matching -
> constraints will *not* cause a mismatch. You must have a constraint
> for every type of operand the predicate allows.
Even this isn't enough. Reload relies on being able to generate a valid
move insn directly, using
insn = emit_insn (gen_rtx_SET (VOIDmode, out, in));
These patterns must match something in your machine description.