Florian Pflug <f...@phlo.org> wrote:
> On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
>> Tom Lane <t...@sss.pgh.pa.us> wrote:
>>
>>> I don't doubt that just duplicating macros and inlineable
>>> functions is a wash performance-wise (in fact, in principle it
>>> shouldn't change the generated code at all).
>>
>> I had the impression that compilers these days could sometimes
>> better optimize across calls to functions with const parameters,
>> because previously-referenced elements of the structures could be
>> trusted to be unchanged across the call. I'm not talking about
>> calls to the inlineable function or macros themselves, but the
>> higher level functions which can then use const.
>
> I don't think that's true. Const (for pointer types) generally
> only means "you cannot modify the value through *this* pointer.
> But there may very well be other pointers to the same object, and
> those may very well be used to modify the value at any time.
>
> So unless both the calling and the called function are in the same
> compilation unit, the compiler needs to assume that any non-local
> (and even local values whose address was taken previously) value
> in the calling function may change as a result of the function
> call. Or at least I think so.
You two seem to be right. I checked some generated code where I
would have expected it to help if it was ever going to, and the
generated code was absolutely identical. It appears that the *only*
real argument for this is to document the function's contract.
Whether the benefit of that outweighs any distraction it causes
seems to be the key argument to be had here.
> If we're concerned about helping the compiler produce better code,
> I think we should try to make our code safe under strict aliasing
> rules. AFAIK, that generally helps much more than
> const-correctness. (Dunno how feasible that is, though)
I hacked my configure file to use strict aliasing and -O3, and my
usual set of regression tests passed. (make check-world, make
installcheck-world against a cluster with
default_transaction_isolation = 'serializable' and
max_prepared_transactions = 10, and make -C src/test/isolation
installcheck against the same cluster)
I did get 10 warnings like this:
warning: dereferencing type-punned pointer will break
strict-aliasing rules
I haven't yet compared code or run benchmarks.
Since 9.2 seems to be shaping up mainly as a performance release,
now might be a good time to review these compile options to see how
far we can now safely push them.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
