[Bug middle-end/82898] Aliasing knowledge is not used to replace memmove with memcpy

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898

--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 8 Nov 2017, antoshkka at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82898
> 
> --- Comment #3 from Antony Polukhin <antoshkka at gmail dot com> ---
> > At least in the gcc model, the type of a pointer is meaningless 
> > as long as you do not dereference it using that type<...>
> 
> OK, does dereferencing the pointers change anything? 
> 
> void foo(int* i, const float* f) {
>     i[0] = f[0]; // Does it triggers the aliasing logic?

for GCC it says that at *f the dynamic type at function entry was
float and after the assignment that of *i is now int.  It doesn't
say that f != i.

You'd have to do

  global_i = *i;
  global_f = *f;

which would be only valid if i != f (and thus they are non-overlapping
because alignof of both is the same as the size)

>     __builtin_memmove(i, f, 1024*1024);
> }
> 
> Code from above still uses memmove, instead of memcpy.

Yes.  For bigger sizes than alignof I'm sure it doesn't work.
For __builtin_memmove (i, f, 4); it doesn't work because we
don't derive context sensitive points-to (and I have a hard
time thinking of an efficient and effective way of doing that).
For the small sizes we instead optimize the memmove as a
read from *f and then a store to *i.