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

Tom Lane wrote:
> Kurt Harriman <harriman@acm.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 islist_head         48 byteslist_tail         48 byteslist_length         48
bytesMemoryContextSwitchTo    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