Re: Patch: Remove gcc dependency in definition of inline functions

From: Kurt Harriman <harriman(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: Remove gcc dependency in definition of inline functions
Date: 2009-12-06 10:21:42
Message-ID: 4B1B85B6.4030301@acm.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Kurt Harriman <harriman(at)acm(dot)org> writes:
>> (Does anybody still use a C compiler that doesn't support
>> inline functions?)

> The question isn't so much that, it's whether the compiler supports
> inline functions with the same behavior as gcc.

With this patch, if the compiler doesn't accept the "inline" keyword
(or __inline or __inline__), then HAVE_INLINE remains undefined, and
the out-of-line definitions are used.

So, these concerns would be applicable in case there is a compiler
which accepts the keyword but ignores it, thus fooling "configure".

(Also these concerns become applicable if we eliminate the
out-of-line definitions altogether as some have suggested.)

> At minimum that would require
> * not generating extra copies of the function

Even if someone uses such a compiler, maybe the extra copies are not
too bad. These are small functions. If not inlined, the compiled
code size on x86-32 is
list_head 48 bytes
list_tail 48 bytes
list_length 48 bytes
MemoryContextSwitchTo 32 bytes
Total 176 bytes
In src/backend there are 478 .c files that #include postgres.h, so the
potential bloat is about 82 KB (= 478 * 176).

This would also occur anytime the user specifies compiler options that
suppress inlining, such as for a debug build; but then the executable
size doesn't matter usually.

> * not whining about unreferenced static functions

I could update the patch so that "configure" will test for this.

(BTW, MSVC is a whiner, but clams up if __forceinline is used.)

> How many compilers have you tested this patch against?

Only a small number. By submitting it to pgsql-hackers, I hope that
it can be exposed to broader coverage.

> Which ones does it actually offer any benefit for?

MSVC is one.

I hope eventually it will be found that all compilers of interest
do a good enough job with static inline functions so that we can
use a lot more of them. For example, I'd like to expunge the
abominable heap_getattr() and fastgetattr() macros in access/htup.h
and replace them with an inline function. Such improvements are
less easily justifiable if they are limited to gcc.

Regards,
... kurt

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-06 10:32:04 Hot standby, recent changes
Previous Message Simon Riggs 2009-12-06 10:08:23 PageIndexTupleDelete