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