Re: const correctness

On Nov9, 2011, at 22:54 , Kevin Grittner wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

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)

best regards,
Florian Pflug