This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH:[darwin] fix load of a misaligned double word
- From: fj <fjahanian at apple dot com>
- To: Bradley Lucier <lucier at math dot purdue dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, dje at watson dot ibm dot com
- Date: Mon, 22 Dec 2003 17:22:10 -0800
- Subject: Re: PATCH:[darwin] fix load of a misaligned double word
On Monday, December 22, 2003, at 04:23 PM, Bradley Lucier wrote:
I have a few questions about this patch.
First, I can't find a message where it's been approved, but it was
committed in
http://gcc.gnu.org/ml/gcc-cvs/2003-12/msg00850.html
This patch was conditionally approved by David Edelsohn after making the
minor change he suggested. Here is text of his message:
From: David Edelsohn <dje@watson.ibm.com>
Date: Fri Dec 19, 2003 6:39:58 PM US/Pacific
To: Fariborz Jahanian <fjahanian@apple.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: PATCH:[darwin] fix load of a misaligned double word
* config/rs6000/rs6000.c (legitimate_offset_address_p): offset of a
DImode/DFmode, etc. must be multiple of 4.
The ChangeLog entry is not accurate and does not represent the change.
- if (TARGET_32BIT)
+ if (TARGET_32BIT && !TARGET_POWERPC64)
Why not just change the test to !TARGET_POWERPC64?
David
Second, I hit this problem myself, and now my code compiles with the
FSF compiler with -mcpu=G5, but my FFT code is 10-20% slower than
before with -mcpu=G4 -mtune=G5. So I'm wondering if this is the right
thing to do.
The Apple assembler was complaining about addresses like 3(r4) for
loads and stores
Apple assembler's complaint is due to architectural limitations of
having offset which
is not multiple of 4 in an ld/std instruction.
of floating-point values. If the value of r4 here is equal to 5
modulo 8, then this seems like a properly aligned memory address
according to the PowerPC programming manuals. Gambit is very careful
to align doubles on 8-byte boundaries, but these are accessed through
char * pointers something like
*(double *)((char *)p+3)
and this generated the misaligned messages like the one mentioned in
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg01788.html
So is gcc at fault and needs to be fixed, as this patch implies, or is
Apple's assembler? Or do I just not understand what's going on here?
Brad