gcc-3.4.0 fails for ColdFire(does not satisfy constraints)

[Ian Lance Taylor]

Peter Barada <peter@the-baradas.com> writes:

> Which is about as good as it can get on ColdFire since there is no
> valid addqi3 pattern.

Ah, now I see why reload was looking for ADDR_REG.  Because
addsi3_5200 has a ?a,a,rJK alternative, and -32 matches the J
constraint.  So I do think the problem is in that insn.  It will tend
to encourage the use of an address register in some cases for which a
general register is appropriate.

> > >is actually worse.  It might be better to not use the 's' constraint,
> > >but to instead use a peephole2 which uses match_scratch, a technique
> > >which was not available when the m68k backend was written.
> 
> Which backend would be a good place to find examples of this type of
> peephole2 pattern?

I dunno, anything really.  See the docs.

Here's a simple one from i386.md; i386.md is probably relevant since
it is also CISC:

(define_peephole2
  [(set (match_operand:SI 0 "push_operand" "")
	(match_operand:SI 1 "memory_operand" ""))
   (match_scratch:SI 2 "r")]
  "! optimize_size && ! TARGET_PUSH_MEMORY"
  [(set (match_dup 2) (match_dup 1))
   (set (match_dup 0) (match_dup 2))]
  "")

This says that if we are trying to push a value loaded from memory,
and we happen to have a free register (as indicated by match_scratch),
then optimize to load the register from memory, and then push the
register.  The resulting two simple instructions are presumably no
slower than the first complex instruction.  This then permits the load
and the push to be scheduled independently.

> What is it that the pattern should do, create a
> scratch register to stuff the constant?

You can use match_scratch to pick up a free register.  If all the
relevant registers are in use, the peephole will not trigger.

> Are peephole2 patterns run
> after reload?

Yes.  They are run after reload, but before the second instruction
scheduling pass.

Ian