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: Problem with ColdFire restricted addressing modes (mode5.6combination)


>Probably not.  reload really only looks at the constraints.  It doesn't
>look at predicates, and it doesn't really look at conditions.
>
>When reload emits an instruction, it will use a named pattern, or try to
>recog it.  But when reload rewrites an instruction, it assumes it will
>be valid if the constraints are satisfied.
>
>Hence the approach of defining new constraints might be better than
>adding a condition to count extension words.

If so, then shouldn't reload have tossed this RTL out since:

>(insn 156 485 157 6 0x4018539c (set (mem/s:HI (plus:SI (reg:SI 9 %a1)
>                (const_int 20 [0x14])) [22 <variable>.FAT_cnt+0 S2 A16])
>        (mem:HI (plus:SI (reg/f:SI 14 %a6)
>                (reg:SI 0 %d0)) [53 file_cnt S4 A16])) 35 {*m68k.md:1076} (nil)
>    (nil))

Doesn't satisfy the constraints of:

(define_insn "movhi_cf"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=r<Q>,g")
	(match_operand:HI 1 "general_operand" "g,r<Q>"))]
  "TARGET_COLDFIRE && !TARGET_CFV4"
  "* return output_move_himode (operands);")

Where the insn needs a g/g constraint to be legal(Q is register indirect).

So why did reload generate/accept this instruction which recog will
accept(since nonimmediate_operand/general_operand is valid for mode
5/6), but the constraint combination doesn't?

-- 
Peter Barada
peter@the-baradas.com


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