Tom Lane wrote:
Kurt Harriman <harri...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
