From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21164 invoked by alias); 27 Apr 2004 15:06:34 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 21119 invoked from network); 27 Apr 2004 15:06:31 -0000 Received: from unknown (HELO mail.simplenet.com) (209.132.4.31) by sources.redhat.com with SMTP; 27 Apr 2004 15:06:31 -0000 Received: (qmail 82030 invoked from network); 27 Apr 2004 15:06:30 -0000 Received: from unknown (HELO ?63.90.75.4?) (63.90.75.4) by mail.simplenet.com with SMTP; 27 Apr 2004 15:06:30 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55A148CC-985C-11D8-9A95-000393D285FA@visionpro.com> Content-Transfer-Encoding: 7bit Cc: llewelly@xmission.com, gcc-help@gcc.gnu.org From: Brian D. McGrew Subject: Re: Optimization Date: Tue, 27 Apr 2004 15:06:00 -0000 To: Ian Lance Taylor X-SW-Source: 2004-04/txt/msg00365.txt.bz2 so what flag can I give gcc to tell it to inline everything, or as much as possible??? Our code already takes 16 hours to build on sparc, using -O2 -g -finline-limit=2750. I've profiled the code but I'm not exactly sure what to do with it now that I've got it. Someone sail something about gproff but I don't know exactly what I'm looking for. -brian Brian D. McGrew { brian@doubledimension.com || pacemakertaker@yahoo.com } -- > YOU! Off my planet! On Apr 27, 2004, at 8:02 AM, Ian Lance Taylor wrote: > Brian D.McGrew writes: > >> As for the -O0 flag, I posted the wrong trace file. In the release >> trees, we use -O2 -g -finline-limit=2750 on all versions, all >> platforms. My bad. > > I doubt this is your problem, but -finline-limit will have a different > effect on i386 and SPARC, since the SPARC will normally require more > instructions. Although -finline-limit is expressed in terms of > pseudo-instructions, gcc pseudo-instructions are different on i386 and > SPARC. It would normally be appropriate to use a larger > -finline-limit on SPARC. > > As I say, I doubt this is your problem. I have no idea what your > problem is. It's fairly unlikely that anybody can tell you what is > wrong here. > > As was already suggested, try using a profiler to see where the hot > spots are in your slow version. Perhaps gcc is egregiously > miscompiling something on SPARC. > > Ian >