Re: PATCH:[darwin] fix load of a misaligned double word

[David Edelsohn <dje at watson dot ibm dot com>]

	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:

        lis 0,0x4038
        sldi 0,0,32
        std 0,-16(1)
        lfd 0,-16(1)
        stfd 0,67(3)
        lis 0,0x4074
        sldi 0,0,32
        std 0,-16(1)
        lfd 0,-16(1)
        stfd 0,75(3)

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
a GPR).

	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
accesses.

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.

David