Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: jimb@codesourcery.com
Cc: muller@ics.u-strasbg.fr, gdb-patches@sourceware.org
Subject: Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors
Date: Wed, 10 Oct 2007 15:51:00 -0000	[thread overview]
Message-ID: <200710101525.l9AFPVcj031852@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <m3hckz3ta9.fsf@codesourcery.com> (message from Jim Blandy on 	Wed, 10 Oct 2007 08:04:30 -0700)

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Wed, 10 Oct 2007 08:04:30 -0700
> 
> 'Daniel Jacobowitz' <drow at false.org> 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.


  reply	other threads:[~2007-10-10 15:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-10  9:07 Pierre Muller
2007-10-10 12:18 ` 'Daniel Jacobowitz'
2007-10-10 14:52   ` Ulrich Weigand
2007-10-10 15:04     ` 'Daniel Jacobowitz'
2007-10-10 15:27   ` Jim Blandy
2007-10-10 15:51     ` Mark Kettenis [this message]
2007-10-11  8:55   ` Update ARI pages Pierre Muller
2007-10-11 14:20     ` 'Daniel Jacobowitz'
2007-10-11 16:53       ` Joel Brobecker
2007-10-15  9:23         ` Pierre Muller
2007-10-24 20:07     ` 'Daniel Jacobowitz'
2007-10-24 20:42       ` Joel Brobecker
2007-10-24 21:06         ` Daniel Jacobowitz
2007-10-25  7:55         ` Pierre Muller
2007-10-11 19:41 ` [RFA] gdb_ari.sh patch to eliminate wrong critical errors Ulrich Weigand
2007-10-15 12:15   ` Pierre Muller
2007-10-15 13:47     ` 'Daniel Jacobowitz'
2007-10-15 13:50     ` Ulrich Weigand
2007-10-15 14:13       ` Ulrich Weigand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200710101525.l9AFPVcj031852@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=jimb@codesourcery.com \
    --cc=muller@ics.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox