Re: powerpc & unaligned block moves with fp registers

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

>>>>> DJ Delorie writes:

DJ> In the case I was originally given, the chip could do misaligned
DJ> integer loads but not misaligned FP loads (I don't know which chip).
DJ> -mno-strict-align allows more compact code/data, so it was too costly
DJ> to give it up just to handle this one problem case properly.

	This seems like a complete kludge to me.  "Customer wants strict
alignment for FPRs but not GPRs".

	Hopefully we can find a way to have the alignment requirement
coincide with the performance issue that Zack, Dale, and I are pursuing.

DJ> Because we can't disallow an unaligned DI move to an FP register.
DJ> You'd never be able to load a 64-bit integer into an FP register
DJ> without them.  Although, if that is unaligned too, it becomes a choice
DJ> between gcc aborting or your program aborting.  I'd choose the program ;-)

	I don't really follow this.  Why would 64-bit integers be
misaligned? 

DJ> And emit_move_insn has no provisions for a movMM failing.

	Okay.  It is unfortunate that whatever is generating the
memory-to-memory move and calling movdi did not first check MOVE_MAX.  If
one has to move a DImode object between memory and registers, one has no
choice.  For memory-to-memory, there is no reason to ignore MOVE_MAX or
SLOW_UNALIGNED_ACCESS.

	This seems like a place where MOVE_MAX should have been tested and
move_by_pieces called instead of generating the emit_move_insn directly.
If not that, then your patch to rs6000_emit_move() needs to use
SLOW_UNALIGNED_ACCESS macro instead of hardcoding the alignment for this
one particular move.

	Using SLOW_UNALIGNED_ACCESS, at worse you can override that macro
with a stricter FPR alignment version for your customer.

David