http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50417
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |sh*-*-* arm*-*-* avr*-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-07-14
CC| |olegendo at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
I ran into this issue when trying out something on SH, too.
(4.9 trunk rev 200571)
Example:
void test (const int* a, int* b)
{
std::memcpy (b, a, 4);
}
Here I'd have expected this to result in a int load + int store, like...
mov.l @r4,r1
rts
mov.l r1,@r5
However, this does not happen. The SH's movmemsi pattern gets a 'common
alignment' of '1'. SH is a strict alignment target and thus the expander will
fall back to memcpy library call.
If I remember correctly, on strict alignment targets a pointer to some type is
by default assumed to satisfy the minimum alignment of that type.
For example
int test (const int* a)
{
return a[0];
}
resuls in (as expected):
rts
mov.l @r4,r0
In the memcpy case it should be safe to assume that the alignment of int* is 32
bit aligned.
As it has been mentioned in PR 52415, I've also tried out
__builtin_assume_aligned and the problem disappears. In this case the memcpy
is eliminated early on and the movmemsi pattern is not used at all.
