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 15:48:05 -0500
- CC: gcc at gcc dot gnu dot org
- References: <200111012026.PAA25118@makai.watson.ibm.com>
> What is your definition of "unaligned"? Anything other than
> natural alignment?
The intent is "anything that causes a trap".
> PowerPC is good at word-aligned FP double-word moves. Less than
> word aligned is discouraged. Is double-word aligned, better? Yes. But
> PowerPC does not require strict alignment.
Are there versions of the ppc chip that do *require* FP moves be
sufficiently aligned? That's the case I'm targetting, not the ones
that are just performance hits.
> Using more loads and stores of smaller units rapidly encounters
> issues about performance hits from more instructions and I-cache usage.
I'm not trying to address a performance hit. I'm trying to address this problem:
PPC tells gcc it can do unaligned DImode moves with
-mno-strict-align. But, an unaligned FP move may trap on some
> It seems that people are generating changes within the PowerPC
> port simply because it is a place to hide these sort of kludges. I don't
> disagree with the goal. I simply have not been convinced that the
> appropriate location for the change has been found.
No amount of cost adjustment will absolutely prevent an unaligned
reference trap on chips that do that, if such a move is the only
option. GCC chooses a movdi because the ppc backend tells it that
such a move would work, when in fact it will not in the case I'm
The only other way I could think of handling this is trying to detect
sufficiently unaligned DI moves, and make using an FP register for
them prohibitively expensive, but under enough register pressure gcc
may still use them.