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

[Peter Barada <peter@the-baradas.com>]

>That's not quite what I was thinking of.  I was thinking that would
>match constants which moveq can handle, which is the reverse of the
>constraints 'K' (if you can't use moveq for the constant, this
>optimization doesn't really help, as far as I can see).  Also, you
>don't need to check symbolic_operand condition, because the constraint
>'K' will only match a CONST_INT anyhow.  I would try something like
>this:
>
>(define_peephole2
>  [(match_scratch:SI 2 "d")
>   (set (match_operand:SI 0 "register_or_memory_operand" "rm")
>        (plus:SI (match_dup 0)
>                 (match_operand:SI 1 "immediate_operand" "J")))]
>  "INTVAL (operand[1]) >= -0x80 && INTVAL (operand[1]) < 0x80"
>  [(set (match_dup 2) (match_dup 1))
>   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
>  "")

I need to ingest more caffeine before I try to write RTL :)  I fat-fingered the 'J'.

For ColdFire(at least on the newer cores), the immediate add is
faster(but larger) than the moveq/add.  If there are data registers
available, will this peephole(if matched multiple times in a block for
the *same* constant), create more than one constant register loaded
with moveq, or is the compiler smart enough to coalesce them together?

I'll give the following a whirl and see what happens:

(define_peephole2
  [(match_scratch:SI 2 "d")
   (set (match_operand:SI 0 "register_or_memory_operand" "rm")
        (plus:SI (match_dup 0)
                 (match_operand:SI 1 "immediate_operand" "J")))]
  "optimize_size && INTVAL (operand[1]) >= -0x80 && INTVAL (operand[1]) < 0x80"
  [(set (match_dup 2) (match_dup 1))
   (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 2)))]
  "")


-- 
Peter Barada
peter@the-baradas.com