This is the mail archive of the
mailing list for the GCC project.
Re: powerpc & unaligned block moves with fp registers
- To: dje at watson dot ibm dot com
- Subject: Re: powerpc & unaligned block moves with fp registers
- From: DJ Delorie <dj at redhat dot com>
- Date: Thu, 1 Nov 2001 19:29:34 -0500
- CC: gcc at gcc dot gnu dot org
- References: <200111020009.TAA25944@makai.watson.ibm.com>
> This seems like a complete kludge to me. "Customer wants strict
> alignment for FPRs but not GPRs".
Yup, but I have no control over the system they're running.
> 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.
> I don't really follow this. Why would 64-bit integers be
long long j;
} x __attribute__((packed));
> Okay. It is unfortunate that whatever is generating the
> memory-to-memory move and calling movdi did not first check MOVE_MAX.
I think it's more fundamental than that. The tree for the struct is
tagged as DI instead of BLK. That shuts off the move_by_pieces logic
completely. (at least, that's what it looked like)
> 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.
I like that idea, but there still needs to be a way to configure
SLOW_UNALIGNED_ACCESS depending on the cpu/os you have.