Florian Weimer <fweimer@bfk.de> wrote:
> * Andres Freund:
>
>> I don't gcc will ever be able to call all possible misusages.
>> E.g. The List api is a case where its basically impossible to
>> catch everything (as gcc won't be able to figure out what the
>> ListCell.data.ptr_value pointed to originally in the general
>> case).
>
> Correct, if code is not strict-aliasing-safe and you compile with
> -f-strict-aliasing, GCC may silently produce wrong code. (Same
> with -fwrapv, by the way.)
I've spent a little time trying to get my head around what to look
for in terms of unsafe code, but am not really there yet. Meanwhile,
I've run a few more benchmarks of -fstrict-aliasing (without also
changing to the -O3 switch) compared to a normal build. In no
benchmark so far has strict aliasing by itself performed better on
my i7, and in most cases it is slightly worse. (This means that
some of the optimizations in -O3 probably *did* have a small net
positive, since the benchmarks combining both showed a gain as long
as there weren't more clients than cores, and the net loss on just
strict aliasing would account for the decrease at higher client
counts.)
From my reading, it appears that if we get safe code in terms of
strict aliasing, we might be able to use the "restrict" keyword to
get further optimizations which bring it to a net win, but I think
there is currently lower-hanging fruit than monkeying with these
compiler options. I'm letting this go, although I still favor the
const-ifying which started this discussion, on the grounds of API
clarity.
-Kevin