This is the mail archive of the
mailing list for the GCC project.
Re: PATCH:[darwin] fix load of a misaligned double word
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Hartmut Penner <hpenner at de dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org, Geoff Keating <geoffk at geoffk dot org>, Andrew Pinski <pinskia at physics dot uc dot edu>, Fariborz Jahanian <fjahanian at apple dot com>
- Date: Thu, 08 Jan 2004 22:46:25 -0500
- Subject: Re: PATCH:[darwin] fix load of a misaligned double word
The patch produces working code, but surprisingly bad code. I had
written a similar patch the previous day, but I did not install it because
reload produces very inefficient code with Brad's example. (My tests are
with with AIX 64-bit mode, not Mac OS X 64-bit instruction mode.) The
code I see generated is:
Instead of combining the constant offset into a base register, the value
is reloaded from a GPR into an FPR. This is the worst of three code
sequences that come to mind (the other options are: adjust the base
register with the offset, or force the REG_EQUIV constant to the local
constant pool and load once from there instead of generating the value in
One could say that because the statement already is going to cause
an alignment trap, the performance of the instuction sequence isn't that
important, but it would be nice to avoid wasting the additional memory
Hartmut> I also tried to change all other ld / std insn using the 'Y'
Hartmut> constraint, but that failed in reload, still chasing the problem.
The LEGITIMATE_ADDRESS macros should prevent this illegal
displacement from being created for DImode addresses (the only other mode
that could use ld/std instructions) -- only DFmode had this unfortunate
conflict. I am not sure that there is any advantage to adding the
complexity of this constraint to DImode patterns. I would be happy to be
enlightened if there is a benefit.