From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2299 invoked by alias); 2 Jan 2003 01:44:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 2292 invoked from network); 2 Jan 2003 01:44:33 -0000 Received: from unknown (HELO desire.geoffk.org) (12.235.56.190) by 209.249.29.67 with SMTP; 2 Jan 2003 01:44:33 -0000 Received: (from geoffk@localhost) by desire.geoffk.org (8.11.6/8.11.6) id h021i3e19835; Wed, 1 Jan 2003 17:44:03 -0800 X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Segher Boessenkool Cc: gcc-patches@gcc.gnu.org Subject: Re: rs6000 fused multiply-add patch [+ patchlet] References: <3E111A25.816F2D1E@koffie.nl> <200212310451.XAA23960@makai.watson.ibm.com> <3E138D45.7F5A0EC0@koffie.nl> From: Geoff Keating Date: Thu, 02 Jan 2003 01:44:00 -0000 In-Reply-To: <3E138D45.7F5A0EC0@koffie.nl> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00061.txt.bz2 Segher Boessenkool writes: > David Edelsohn wrote: > > > > The combine pass is called "combine" because it is predicated on > > combining instructions and uses decreased instructions as the goal. > > Yes, I understand that. > > > If more optimal instruction sequences should be used, that needs to be > > optimized by a different pass. Your bitfield+mfcr -> logic instruction > > example might be appropriate as define_peephole2 patterns. Your load+mask > > -> narrower load already should be handled correctly by other > > optimizations or the combiner because it seem like it should decrease the > > number of instructions. > > Well, all these optimizations are already there, in simplify-rtx.c etc., it's > just that they never get done by the current combine, because it doesn't > decrease the number of rtl insns _if looking through a very small (3 insn) > window_. What you usually do in this case is create a combination insn+splitter to give combine an appropriate intermediate result. If you could provide testcases/code samples for the cases you mention, it would be easier to see precisely what's going on. Often several iterations and many eyes are necessary to get the proper fix. It is also possible that some rearchitecting of combine might be necessary, but that's something that would require careful consideration and an examination of all the possible alternatives, not an ad-hoc patch to solve a specific problem. > > If the code size is decreasing then the number of > > instructions is decreasing, so maybe we need to add patterns transforming > > three instructions into two instructions. > > That's a lot of different patterns; also, it's not only 3->2, but also 4->3 > and I saw an 8->7, even. -- - Geoffrey Keating