Spraul [EMAIL PROTECTED]
To: Tom Lane [EMAIL PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; Patches (PostgreSQL)
[EMAIL PROTECTED]
Sent: Tuesday, October 14, 2003 5:01 PM
Subject: Re: [PATCHES] fix for strict-alias warnings
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
After
Andrew Dunstan [EMAIL PROTECTED] writes:
All this is interesting, but the real problem remains that we don't know
what else might be affected because gcc apparently doesn't promise to
tell us. IMO the gcc team made a bad mistake by turning this on by
default for -O2 without reliable
Andrew Dunstan [EMAIL PROTECTED] writes:
Interestingly, a lot of the comparison and call to memset() still seem to be
optimised away, but the loop from MemSet is left, so the multiplication is
also not optimised away.
Yeah, I saw the same in gcc 3.2 (on Intel) yesterday. I thought maybe
3.3
Andrew Dunstan [EMAIL PROTECTED] writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers - which makes things somewhat easier for them. What is our target
set of compilers? What is our
Tom Lane wrote:
BTW, I haven't looked at the problem spots in detail. How many of them
are due to the use of MemSet in conjunction with other access to a chunk
of memory? ISTM that we need not worry about code motion around a
MemSet call, since that would require the compiler to prove that the
Andrew Dunstan wrote:
there were 3 calls to MemSet it complained about - all in
src/backend/storage/lmgr/proc.c, and all zeroing out the timeval
structure. (is MemSet actually a gain in this instance?)
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Of course, the linux kernel is aimed at a limited set of compilers - as I
understand it basically gcc although it has been made to build with Intel
compilers
icc once compiled the kernel. But they had to teach it quite a lots of
Peter Eisentraut wrote:
Andrew Dunstan writes:
And looking at it even closer, 2 of the 3 cases of calling MemSet appear
to be unnecessary, as the zeroed out values are immediately overwritten.
We need to zero out the holes in the structures so that hash functions
work correctly.
I
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on plenty of different
Manfred Spraul [EMAIL PROTECTED] writes:
I've asked the question on the gcc devel list. The first reply was that
MemSet violates strict aliasing rules:
No doubt it does, but that is not really the issue here; the issue IMHO
is whether there is any real risk involved. Remember that the macro
Tom Lane wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
We will not be doing the latter, for certain.
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it? Would someone profile PostgreSQL
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Given that gcc is smart enough not to move any code across the memset()
call,
Is it?
It had better be.
regards, tom lane
---(end of broadcast)---
TIP 8:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what gcc versions support -fno-strict-aliasing? Do we need a
configure test for it?
Perhaps ... although it is recognized in 2.95.3 and probably for a good
ways before that.
It looks to me like what has changed in gcc 3.3 is not
Neil Conway writes:
On Tue, 2003-10-14 at 15:00, Manfred Spraul wrote:
I think we must either add -fno-strict-aliasing, or switch to the c
compiler memset functions for gcc.
The last time we did some benchmarking, using the builtin memset()
imposes a significant performance penalty on
On Tue, 2003-10-14 at 16:29, Peter Eisentraut wrote:
The last time I did some testing, the builtin memset() was significantly
faster on plenty of different platforms.
Oh? Which platforms are you referring to, and what tests were performed?
You can find the benchmark results I'm referring to in
Manfred Spraul [EMAIL PROTECTED] writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about the MemSetAligned case.
Neil Conway writes:
Oh? Which platforms are you referring to, and what tests were performed?
http://archives.postgresql.org/pgsql-patches/2002-10/msg00085.php
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if
Tom Lane wrote:
Manfred Spraul [EMAIL PROTECTED] writes:
After some massaging, I've succeeded in generating bad code using a
slightly modified MemSetAligned macro (parameters -O2
-fstrict-aliasing): gcc pipelined the x*x around the memset.
As I already explained, we do not care about
Manfred Spraul [EMAIL PROTECTED] writes:
Tom Lane wrote:
Is gcc 3.3 smart enough to optimize away the pointer alignment test
in the full macro?
3.2 optimizes away the pointer alignment test, but then doesn't pipeline
the x*x calculation.
Hm, confirmed here. So indeed it seems that Bruce
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Even without the extra overhead, the danger of strict-aliasing is not just
related to alignment.
If I understand the issue at all, it has *nothing* to do with alignment.
As I understand it, given strict-aliasing assumptions
the
Andrew Dunstan wrote:
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
I have backed out the patch.
Looking at the case in tablecmds.c and proc.c, the first was assigning a
struct with a NodeTag pointer as its first element to another struct
with NodeTag as its
Patch applied. Thanks.
---
Andrew Dunstan wrote:
This patch will stop gcc from issuing warnings about type-punned objects when
-fstrict-aliasing is turned on, as it is in the latest gcc when you use -O2
enjoy
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I hope you applied it with the additional changes you asked for ---
at the very least, cast to (void*) and then to the destination type.
As-is, the patch simply suppresses all error detection for these
conversions, which seems a bad
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Patch applied. Thanks.
I hope you applied it with the additional changes you asked for ---
at the very least, cast to (void*) and then to the destination type.
As-is, the patch simply suppresses all error detection for these
to contemplate that.
cheers
andrew
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED]
Cc: Andrew Dunstan [EMAIL PROTECTED]; PG Patches
[EMAIL PROTECTED]
Sent: Saturday, October 11, 2003 1:29 PM
Subject: Re: [PATCHES] fix for strict-alias warnings
Bruce
Andrew Dunstan wrote:
Tough words! :-)
ISTM the best thing would be to back out the patch, add -fno-strict-aliasing
for gcc, and add a TODO to fix this thoroughly.
Having -fstrict-aliasing on and ignoring the warnings doesn't seem like a
sound strategy. I think we should fix it or turn it
27 matches
Mail list logo
