From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5669 invoked by alias); 10 Oct 2007 15:27:02 -0000 Received: (qmail 5605 invoked by uid 22791); 10 Oct 2007 15:27:01 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 10 Oct 2007 15:26:56 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id l9AFPVdS002262; Wed, 10 Oct 2007 17:25:31 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id l9AFPVcj031852; Wed, 10 Oct 2007 17:25:31 +0200 (CEST) Date: Wed, 10 Oct 2007 15:51:00 -0000 Message-Id: <200710101525.l9AFPVcj031852@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: jimb@codesourcery.com CC: muller@ics.u-strasbg.fr, gdb-patches@sourceware.org In-reply-to: (message from Jim Blandy on Wed, 10 Oct 2007 08:04:30 -0700) Subject: Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors References: <000001c80b14$db947450$92bd5cf0$@u-strasbg.fr> <20071010120140.GB10228@caradoc.them.org> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00244.txt.bz2 > From: Jim Blandy > Date: Wed, 10 Oct 2007 08:04:30 -0700 > > 'Daniel Jacobowitz' writes: > >> 1) inline 9 Do not use the inline attribute; > >> since the compiler generally ignores this, better > >> algorithm selection is needed to improved performance > >> This problem is limited to three files: > >> vec.c (1) vec.h (7) and xtensa-tdep.c (1). > >> It could be easily removed, but I was wondering if > >> there was a special reason why vec.h > >> had some many. > > > > No really good reason. The above is someone's particular opinion on > > the inline keyword (probably Andrew's, as he wrote the ARI stuff, but > > I don't know for sure who - maybe someone else on the list knows). > > vec.c / vec.h were written by Nathan for GCC, and the GCC project has > > a very different opinion on the use of the inline keyword. > > > > Perhaps the fact that the compiler sources think inline is worthwhile > > should give us a hint... > > Yeah, I'm not sure I agree with the ARI's opinion either. GDB has > plenty of room for algorithmic improvements, but if adding an 'inline' > to a particular function made it go faster, why not use it? The point is that in many cases it doesn't. Inlining generally increases code size, and therefore tends to increase cache pressure, which often results in slower code. And of course it makes code much harder to debug.