Florian Weimer <fwei...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers