This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] gdb_ari.sh patch to eliminate wrong critical errors


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]