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

[Alan Modra]

On Tue, Feb 24, 2004 at 07:07:10AM +0100, Ulrich Weigand wrote:
> Geoff Keating wrote:
> 
> >> Disallowing both reverts back to gcc-3.3 behaviour, which loses
> >> performance on certain code.  Allowing both means that "offset & 3"
> >> gpr loads/stores must be fixed some other way.  Now this is where I
> >> start to handwave.  What should be done about "some other way"?
> >> Hartmut's reload patterns, perhaps with tighter reg constraints?
> >> Please give us your thoughts on this.
> >
> >We should allow them.  "Some other way" is to use constraints.
> 
> However, constraints are only evaluated for insns already existing
> before reload.  The insns reload itself generates are not checked
> against any constraints -- it is assumed that any move-type insn
> (with legitimate operands) will be valid, *or else* there will be
> a secondary reload to perform the move.

I think that we can do without any of the reload_in and reload_out
patterns that Hartmut was using.  I'll post a patch when I've done
some testing, and proven whether I know what I'm talking about or
not.  :)

Attached is a testcase that I developed while looking at current gcc
behaviour (good for -mpowerpc64 only).  Mainline doesn't do too badly,
with only f7 generating poor code.

.f7:
        std 4,-16(1)
        lfd 0,-16(1)
        stfd 0,3(3)
        blr

Better would be

.f7:
        addi 3,3,3
        std 4,(3)
        blr

Not introducing any regressions with this testcase, and fixing f7 is
proving not so easy..  At this point, I think find_reloads needs a tweak
to discourage it choosing an alternative that we _know_ will need
secondary memory over an alternative that just needs an output reload.
More on this later.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre