[Bug tree-optimization/50417] regression: memcpy with known alignment

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Georg-Johann Lay from comment #18)
> (In reply to rguenther@suse.de from comment #12)
> > On Fri, 8 Jul 2016, olegendo at gcc dot gnu.org wrote:
> > 
> > > void test (const int *a, int *b)
> > > {
> > >   a[100] = 1;
> > >   b[200] = 2;
> > > 
> > >   std::memcpy ((char *)b, (char *)a, t);
> > > }
> > > 
> > > where a[100] and b[200] both would result in 32 bit accesses, not 4x1 byte or
> > > something, because the base pointer is assumed to be int aligned.
> > 
> > No, because the access is performed as 'int'.
> > 
> > >  Why should memcpy be any different?
> > 
> > Because the memcpy stmt doesn't constitute a memory access but a function
> > call.
> 
> What about a new command option like -fassume-aligned-xxx that's off per
> default?
> 
> The user could assert that when she is using memcpy (and friends) with a
> pointer of a specific type, then that also asserts that the data behind the
> pointer is appropriately aligned and may be accessed accordingly.

But if you do

void copy (int *d, int *s)
{
  memcpy ((char *)d, (char *)s, 4);
}

then you will get aligned accesses because all the middle-end sees is

  mempcy (d, s, 4);

so as I said elsewhere the only way to reliably implement deriving alignment
from pointer types is by the frontends inserting __builtin_assume_aligned
calls before they possibly stripped any conversions.

Yes, if we simply say we strictly follow C11 6.3.2.3/7 we can do that
using a simple flag.  But we won't get the optimization reliably because
of the above issue for the variant with char * parameters and int * casts.
You could call that flag -fstrict-alignment (though maybe that would be
confusing to people familiar with GCC internals STRICT_ALIGNMENT target
macro).  A simple implementation could be in get_pointer_alignment_1,
wrapping it with a function that inspects TYPE_ALIGN (TREE_TYPE (TREE_TYPE
(exp)) and uses that if it trumps the wrapped fn return values.  But I
expect much undesired fallout from such a change.

Having a flag restricting the optimization behavior to memcpy-and-friends
is not going to work (without the frontends inserting extra IL when all
information is still present).