From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31587 invoked by alias); 13 Apr 2007 14:25:17 -0000 Received: (qmail 31099 invoked by uid 22791); 13 Apr 2007 14:25:11 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 13 Apr 2007 15:25:07 +0100 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1HcMbm-00056d-00; Fri, 13 Apr 2007 15:18:38 +0100 Received: from ukcvpn36.mips-uk.com ([192.168.193.36]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1HcMbg-00084m-00; Fri, 13 Apr 2007 15:18:32 +0100 Message-ID: <461F9137.3080000@mips.com> Date: Fri, 13 Apr 2007 15:23:00 -0000 From: Nigel Stephens User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: richard@codesourcery.com CC: "Fu, Chao-Ying" , gcc@gcc.gnu.org, "Thekkath, Radhika" Subject: Re: [MIPS] MADD issue References: <3CB54817FDF733459B230DD27C690CEC03EE8E3F@Exchange.mips.com> <87r6qopgn7.fsf@firetop.home> In-Reply-To: <87r6qopgn7.fsf@firetop.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2007-04/txt/msg00463.txt.bz2 Richard Sandiford wrote: > > As far as madd goes, I think it would be better to either > (a) get combine to handle this situation or (b) get expand > to generate a fused multiply-add from the outset. > > (b) sounds like it might be useful in its own right. At the moment we > treat the generation of floating-point multiply-adds as an optimisation, > but in some applications it's critical not to round the intermediate > result. (I don't know if there's a bugzilla entry about this.) > If we treated fused multiply-add as a primitive operation, we could > extend it to integer types too. In this case we'd also need to > handle widening multiplications, but we already need to do that > for stand-alone multiplications. > Richard While I agree with you philosophically, it feels like (b) might be quite a major task. A number of optimisation passes which currently recognise and MUL and PLUS separately (e.g. loop strength reduction) would now need to be extended to handle the fused MULPLUS and MULSUB operators. And although the reduction in instruction count due to your previous change is good, what is it as a percentage of the total? After all it only helps code which uses 64-bit integer types with a 32-bit ABI, which is probably quite a small proportion of most real-life applications -- whereas for some algorithms the ability to use MADD is absolutely critical to performance, and for them losing the ability to generate MADD is a significant backward step for the compiler. How about, as a workaround until (b) sees the light of day, we reimplement adddi3 and subdi3 only (not the other di mode patterns), qualified by ISA_HAS_MADD_MSUB. Perhaps they could also be implemented more cleanly nowadays, using define_insn_and_split and/or a "#" template, to avoid generating multi-instruction assembler sequences. Nigel