This is the mail archive of the
mailing list for the GCC project.
Re: powerpc & unaligned block moves with fp registers
- To: DJ Delorie <dj at redhat dot com>
- Subject: Re: powerpc & unaligned block moves with fp registers
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Thu, 01 Nov 2001 19:09:33 -0500
- cc: gcc at gcc dot gnu dot org
>>>>> 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
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
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.