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
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 |