On 9/08/2012, at 7:10 AM, Richard Sandiford wrote:

> Hmm, yeah, it does look like they should be using mips_linked_madd_p
> instead, except that mips_linked_madd_p isn't yet wired up to handle
> DSP macs.  Rather than pattern-match them all, the easiest thing would
> probably be to define a new attribute along the lines of:
> 
> (define_attr "accum_in" "none,0,1,2,3,4,5" (const_string "none"))
> 
> and use it for the existing imadds too.  E.g.:
> 
> (define_insn "*mul_acc_si"
>  [(set (match_operand:SI 0 "register_operand" "=l*?*?,d?")
>       (plus:SI (mult:SI (match_operand:SI 1 "register_operand" "d,d")
>                         (match_operand:SI 2 "register_operand" "d,d"))
>                (match_operand:SI 3 "register_operand" "0,d")))
>   (clobber (match_scratch:SI 4 "=X,l"))
>   (clobber (match_scratch:SI 5 "=X,&d"))]
>  "GENERATE_MADD_MSUB && !TARGET_MIPS16"
>  "@
>    madd\t%1,%2
>    #"
>  [(set_attr "type"    "imadd")
>   (set_attr "accum_in" "3")
>   (set_attr "mode"    "SI")
>   (set_attr "length"  "4,8")])
> 
> Then mips_linked_madd_p can use get_attr_accum_in to check for chains.
> 

I thought I'll butt in since I did a very similar thing for sync_memmodel a 
couple of months ago.

Is the attached patch what you have in mind?  It is a standalone change by 
itself and can be checked in if OK.  Sandra can than adjust DSP patches she's 
working on to use mips_linked_madd_p.

OK to apply if no regressions?

Thanks,

--
Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Attachment: accum_in.ChangeLog
Description: Binary data

Attachment: accum_in.patch
Description: Binary data



Reply via email to