Re: movmem pattern and missed alignment

[Paul Koning <paulkoning at comcast dot net>]

> On Oct 8, 2018, at 11:09 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
> On Mon, Oct 8, 2018 at 3:57 PM Paul Koning <paulkoning@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