On Fri, Jan 8, 2016 at 12:40 PM, Eric Botcazou <ebotca...@libertysurf.fr> wrote:
>> I think we only assume it if the pointer is actually dereferenced, otherwise
>> it just breaks too much code in the wild.  And while memcpy dereferences,
>> it dereferences it through a char * cast, and thus only the minimum
>> alignment is assumed.
>
> Yet the compiler was generating the expected code for Steve's testcase on
> strict-alignment architectures until very recently (GCC 4.5 IIUC) and this
> worked perfectly.
>
> The irony of this very questionable change is that it was made to support some
> corner cases with SSE on x86

Well, it was made to make alignment propagation possible in a sensbile way
and to make all those pointer conversions useless.  We backtracked on the
SSE x86 case with relying on the alignment stored in memory references.
But of course memcpy isn't a "memory reference" in the GCC IL sense.

> but of course the compiler generates the expected
> code for Steve's testcase on x86 because it is _not_ strict-alignment...

Sure.

Consider

int a[256];
int
main()
{
  void *p = (char *)a + 1;
  void *q = (char *)a + 5;
  __builtin_memcpy (p, q, 4);
  return 0;
}

where the ME would be entitled to "drop" the char */void * conversions
and use &a typed temps.

Richard.

> --
> Eric Botcazou

Reply via email to