This is the mail archive of the 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: [PATCH, MIPS] 74k madd scheduler tweaks

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"))]
>  "@
>    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?


Maxim Kuvyrkov
CodeSourcery / Mentor Graphics

Attachment: accum_in.ChangeLog
Description: Binary data

Attachment: accum_in.patch
Description: Binary data

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