On 11/30/09, Bruce Momjian <bruce@momjian.us> wrote:
> Peter Eisentraut wrote:
> > On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
> > > I thought one problem was that inline is a suggestion that the compiler
> > > can ignore, while macros have to be implemented as specified.
> >
> > Sure, but one could argue that a compiler that doesn't support inline
> > usefully is probably not the sort of compiler that you use for compiling
> > performance-relevant software anyway. We can support such systems in a
> > degraded way for historical value and evaluation purposes as long as
> > it's pretty much free, like we support systems without working int8.
>
>
> The issue is that many compilers will take "inline" as a suggestion and
> decide if it is worth-while to inline it --- I don't think it is inlined
> unconditionally by any modern compilers.
>
> Right now we think we are better at deciding what should be inlined than
> the compiler --- of course, we might be wrong, and it would be good to
> performance test this.
Note - my proposal would be to get rid of HAVE_INLINE, which
means we are already using inline functions unconditionally
on platforms that matter (gcc). Keeping duplicate code
for obsolete compilers is pointless.
I'm not suggesting converting all existing macros to inline. This
can happen slowly, and where it brings benefit (short but multi-arg
are probably most worthwhile to convert). Also new macros are better
done as inlines.
About uninlining - usually if the compiler decides to uninline,
it is probably right anyway. The prime example would be Linux kernel
where the 'inline' is used quite a lot as go-faster-magic-dust on totally
random functions. (In .c files, not talking about headers)
Most compilers (gcc, vc, icc) support also force-inlining, which is
not taken as hint but command. If you want to be on safe side, you
could define 'inline' as force-inline on compilers that support that.
--
marko
