On Thu, Oct 4, 2012 at 7:44 PM, Joe Buck <joe.b...@synopsys.com> wrote:
>
> On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee <w...@tilera.com> wrote:
>> > On TILE-Gx, I'm observing a degradation in inlined memcpy/memset in
>> > gcc 4.6 and later versus gcc 4.4. Though I find the problem on
>> > TILE-Gx, I think this is a problem for any architectures with
>> > SLOW_UNALIGNED_ACCESS set to 1.
>> >
>> > Consider the following program:
>> >
>> > struct foo {
>> > int x;
>> > };
>> >
>> > void copy(struct foo* f0, struct foo* f1)
>> > {
>> > memcpy (f0, f1, sizeof(struct foo));
>> > }
>> >
>> > In gcc 4.4, I get the desired inline memcpy: ...
>> > In gcc 4.7, however, I get inlined byte-by-byte copies: ...
>
> On Thu, Oct 04, 2012 at 01:58:54PM +0200, Richard Guenther wrote:
>> There is no way to fix it. memcpy does not require aligned arguments
>> and the merely presence of a typed pointer contains zero information
>> of alignment for the middle-end. If you want to excercise C's notion
>> of alignemnt requirements then do not use memcpy but
>>
>> *f0 = *f1;
>>
>> which works equally well.
>
> Perhaps I'm missing something. While memcpy is not permitted to assume
> alignment of its arguments, copy is. Otherwise, if I wrote
>
> void copy(struct foo* f0, struct foo* f1)
> {
> *f0 = *f1;
> }
>
> the compiler would also be forbidden from assuming any alignment. So,
> when compiling "copy", do we lack the information that the memcpy call is
> to the standard ISO memcpy function? If we know that it is the standard
> function we should be able to do the copy assuming everything is properly
> aligned.
If we see the above aggregate copy then we should be able to compile
the function assuming that f0 and f1 are properly aligned for type struct foo.
If we see C source code using memcpy (f0, f1, sizeof (struct foo)) then
we cannot assume anything about the alignment of f0 or f1 based on the
fact that the code uses the ISO memcpy function.
Thus, I do not understand your question. When we compile "copy" how
is memcpy relevant?
Richard.
>
>
>> Btw, the new beavior even fixed bugs.
>
> Could you point to a PR that was fixed by the change? There must be some
> way to distinguish this case from those cases.
