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: Question about movM insn restrictions


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

R.



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