From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14488 invoked by alias); 4 Mar 2003 05:24:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14475 invoked from network); 4 Mar 2003 05:24:25 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by 172.16.49.205 with SMTP; 4 Mar 2003 05:24:25 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.8/8.12.8) with ESMTP id h245OO8F011439; Tue, 4 Mar 2003 00:24:24 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.8/8.12.8/Submit) id h245ONJe011437; Tue, 4 Mar 2003 00:24:23 -0500 (EST) Message-Id: <200303040524.h245ONJe011437@hiauly1.hia.nrc.ca> Subject: Re: Is the loop pass allowed to introduce new call insns? To: rth@redhat.com (Richard Henderson) Date: Tue, 04 Mar 2003 05:29:00 -0000 From: "John David Anglin" Cc: law@redhat.com, gcc@gcc.gnu.org In-Reply-To: <20030304005720.GO12472@redhat.com> from "Richard Henderson" at Mar 3, 2003 04:57:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00153.txt.bz2 > On Mon, Mar 03, 2003 at 07:17:47PM -0500, John David Anglin wrote: > > xmpyu was not used because the option -mdisable-fpregs was used, > > disabling the pattern. The test code is from a parisc-linux > > kernel build. Whether it is this is the best choice on a PA 2 > > machine, I'm not sure. > > Would it be feasable to simply make all of the fpregs call-saved? > Alternately, leave a few of them unfixed, as we do with ia64. I'd have to run the idea past the kernel people. It would improve multiplication performance at the expense of context switching for the unfixed fpregs. I have hacked the pa call patterns to not use the virtual outgoing args register after instantiation. This can fail if insufficient argument space is allocated. But I suspect that when loop generates an add-multiply there already will be a similar set of libcalls in the loop and we won't need any additional arg space. It fixes the test compile. We allocate stack space for 8 DI mode argument registers whenever there is a call. The final option might be to use the 32-bit $$mulI millicode routine instead of the __muldi3 libcall. It doesn't use the stack or create a frame. The downside is it only produces a 32-bit result. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)