From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8185 invoked by alias); 20 Apr 2007 14:32:16 -0000 Received: (qmail 8177 invoked by uid 22791); 20 Apr 2007 14:32:15 -0000 X-Spam-Check-By: sourceware.org Received: from gateway.codesourcery.com (HELO gateway.codesourcery.com) (65.74.133.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Apr 2007 15:32:13 +0100 Received: (qmail 2305 invoked by uid 1010); 20 Apr 2007 14:32:11 -0000 From: Richard Sandiford To: Nigel Stephens Mail-Followup-To: Nigel Stephens ,"Fu, Chao-Ying" , gcc@gcc.gnu.org, "Thekkath, Radhika" , 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> <461F9137.3080000@mips.com> <87irc0pb0b.fsf@firetop.home> <4628C903.6060607@mips.com> Date: Fri, 20 Apr 2007 14:44:00 -0000 In-Reply-To: <4628C903.6060607@mips.com> (Nigel Stephens's message of "Fri, 20 Apr 2007 15:06:59 +0100") Message-ID: <87tzvbyv4k.fsf@firetop.home> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00702.txt.bz2 Nigel Stephens writes: > I notice that at least the 32-bit rs6000, i386, sparc, frv, sh, cris, > mcore, score, arm & pa backends still implement adddi3 as either a > define_insn which outputs two instructions or an explicit define_expand > followed define_split and associated sub patterns. Are we setting the > bar too high for MIPS? :) I don't think that follows. The main reason that ports like rs6000, i386, arm, sparc and pa define adddi3 is because those architectures provide special add-with-carry type instructions, or similar architecture-specific optimisations. MIPS has nothing like that. The old MIPS patterns just re-implemented the standard optabs version (and often did so less efficiently, as I said before). > Whilst I'm sure that your proposal is the right one going forward, it > still feels like it could be significant amount of work to implement. > And the simplified optab/expand support would only work for multiply-add > sequences expressed within a single expression, and wouldn't be able to > optimise disjoint multiply, then add expressions. Or have I missed > something. I don't think that follows either. Out-of-ssa should coalesce them if they are in the same basic block. And if they aren't in the same basic block, that's presumably because the tree optimisers think they shouldn't be. Combine wouldn't look across basic block boundaries either AFAIK. E.g. compiling: -------------------------------------------------------------------- typedef unsigned long long ull; typedef unsigned int ui; ull foo (ui x, ui y, ull z) { ull tmp = (ull) x * y; return tmp + z; } -------------------------------------------------------------------- with a recent snapshot and "-O2 -fdump-tree-all" shows that the final_cleanup dump does indeed have the combined form: -------------------------------------------------------------------- ;; Function foo (foo) foo (x, y, z) { : return (long long unsigned int) y * (long long unsigned int) x + z; } -------------------------------------------------------------------- I realise no-one else has spoken out in support of me, so perhaps I'm in a minority of one here. But it does seem to me that in the Tree-SSA world, it makes less sense to duplicate standard optabs in the backend purely for the reason of keeping DImode arithmetic around as DImode arithmetic for longer. > in the short term we really do need to reenable madd/msub for MIPS32 > targets in GCC 4. We could do that with a local patch to put back > adddi3, but it would be better if we could coordinate this with you. If removing the patterns had been purely a clean-up, I would be more open to the idea of putting the patterns back. But given that removing the patterns had an optimisation benefit of its own, I'm less open to the idea of adding them back, especially when (as far as I'm concerned) there's a clean way of getting the best of both worlds. Richard