On 26/10/2010 17:16, Paul Koning wrote:
> On Oct 25, 2010, at 9:28 PM, Dave Korn wrote:
>
>> On 26/10/2010 01:53, Paul Koning wrote:
>>> On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
>>>
>>>> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning <paul_kon...@dell.com>
>>>> wrote:
>>>>> Question on movmemm:
>>>>>
>>>>> Given
>>>>>
>>>>> extern int *i, *j; void foo (void) { memcpy (i, j, 10); }
>>>>>
>>>>> I would expect to see argument 4 (the shared alignment) to be
>>>>> sizeof(int) since both argument are pointers to int. What I get
>>>>> instead is 1. Why is that?
>>>> Because the int * could point to unaligned data and there is no access
>>>> that would prove otherwise (memcpy accepts any alignment).
>>> Ok, but if I do a load on an int*,
>> I think that is what Richard meant by an "access that would prove
>> otherwise".
>>
>>> I get an aligned load, not an unaligned
>>> load, so in all those other cases there *is* an assumption that an int*
>>> contains a properly aligned address.
>> This is a bit like GCC optimising away a null-pointer check if it knows
>> you've already dereferenced the pointer. Either you've already crashed by
>> then, or it doesn't matter.
>>
>> What happens if you dereference i and j before the memcpy in foo? Do you
>> then get int-sized shared alignment in movmemM?
>>
>> extern int *i, *j; void foo (void) { *i; *j; memcpy (i, j, 10); }
>
> That doesn't make any difference; I still get alignment 1.
>
That sounds like a missed optimisation opportunity to me, but maybe there's
some reason the compiler can't infer a larger alignment. (Or maybe the reads
got discarded, you might need volatile to avoid that?)
cheers,
DaveK
