> On Oct 8, 2018, at 11:09 AM, Richard Biener <richard.guent...@gmail.com>
> wrote:
>
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning <paulkon...@comcast.net> wrote:
>>
>> I have a movmem pattern in my target that pays attention to the alignment
>> argument.
>>
>> GCC isn't passing in the expected alignment part of the time. I have this
>> test case:
>>
>> extern int *i, *j;
>> extern int iv[40], jv[40];
>>
>> void f1(void)
>> {
>> __builtin_memcpy (i, j, 32);
>> }
>>
>> void f2(void)
>> {
>> __builtin_memcpy (iv, jv, 32);
>> }
>>
>> When the movmem pattern is called for f1, alignment is 1. In f2, it is 2
>> (int is 2 bytes in pdp11) as expected.
>>
>> The compiler clearly knows that int* points to aligned data, since it
>> generates instructions that assume alignment (this is a strict-alignment
>> target) when I dereference the pointer. But somehow it gets it wrong for
>> block move.
>>
>> I also see this for the individual move operations that are generated for
>> very short memcpy operations; if the count is 4, I get four move byte
>> operations for f1, but two move word operations for f2.
>>
>> This seems like a bug. Am I missing something?
>
> Yes, memcpy doesn't require anything bigger than byte alignment and
> GCC infers alignemnt
> only from actual memory references or from declarations (like iv /
> jv). For i and j there
> are no dereferences and thus you get alignment of 1.
>
> Richard.
Ok, but why is that not a bug? The whole point of passing alignment to the
movmem pattern is to let it generate code that takes advantage of the
alignment. So we get a missed optimization.
paul
