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
accum_in.ChangeLog
Description: Binary data
accum_in.patch
Description: Binary data