This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inlined memcpy/memset degradation in gcc 4.6 or later
On Tue, Oct 2, 2012 at 4:19 PM, Walter Lee <walt@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.
> 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.