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 rguent...@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).
