Re: powerpc & unaligned block moves with fp registers

[Zack Weinberg <zack at codesourcery dot com>]

On Thu, Nov 01, 2001 at 07:29:34PM -0500, DJ Delorie wrote:
> 
> > 	Hopefully we can find a way to have the alignment requirement
> > coincide with the performance issue that Zack, Dale, and I are pursuing.
> 
> That would be good.

Just for the record: Although I am working on the same basic problem,
the situation I'm concerned with involves a correctness issue, not a
performance issue.  Under VxWorks, a mode is necessary where floating
point registers are *never* used for integer operations.  Alignment
has nothing to do with it.

My current candidate fix for this is to create two movdi insns:

(define_insn "*movdi_32_fpu"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=f,f,m")
	(match_operand:DI 1 "input_operand" "f,m,f")]
  "! TARGET_POWERPC64 && TARGET_IMPLICIT_FP ..."
  ...)

(define_insn "*movdi_32"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,*f,*f,m,r,r,r,r,r")
	(match_operand:DI 1 "input_operand" "r,m,r,*f,m,*f,IJK,n,G,H,F")]
  "! TARGET_POWERPC64 ..."
  ...)

where TARGET_IMPLICIT_FP is set true iff the compiler is allowed to
generate floating-point load/store for integer ops.

I leave the floating point alternatives in the second movdi insn
because they are necessary for the float/int conversion sequence:
fixdfdi etc expect or leave integers in the floating point registers.

There is a performance concern, or I would not bother creating the
FP-only insn.  This instruction sequence

	lfd	0, (9)
	stfd	0, (10)

is near-as-makes-no-difference twice as fast as

	lwz	0, 0(9)
	lwz	1, 4(9)
	stw	0, 0(10)
	stw	1, 4(10)

as measured by the decrementer register on a ppc604 embedded board.
In this test the addresses in regs 9 and 10 were properly aligned; I
don't have the code in front of me so I can't tell you if it was 32-
or 64-bit aligned, but there were no unaligned traps issuing.

Therefore, it makes sense to retain the ability to generate the
floating-point DImode moves.  TARGET_IMPLICIT_FP is controllable by an
-m switch, and defaults to something sensible for the OS and CPU.  I
imagine most general purpose OSs would want to leave it on by default.

(Complete test code available on request.  I may have misremembered
the register numbers - please treat them as metavariables.)  

I'm open to better suggestions for how to solve the problem, as long
as they remain suggestions for changes to the rs6000 back end.  I am
convinced that dinking with the RTL generator is the wrong approach.

zw