On Tue, Oct 9, 2018 at 10:02 AM Andrew Haley <a...@redhat.com> wrote:
>
> On 10/08/2018 07:38 PM, Paul Koning wrote:
> >
> >
> >> On Oct 8, 2018, at 1:29 PM, Andrew Haley <a...@redhat.com> wrote:
> >>
> >> On 10/08/2018 06:20 PM, Michael Matz wrote:
> >>> Only if you somewhere visibly add accesses to *i and *j. Without them you
> >>> only have the "accesses" via memcpy, and as Richi says, those don't imply
> >>> any alignment requirements. The i and j pointers might validly be char*
> >>> pointers in disguise and hence be in fact only 1-aligned. I.e. there's
> >>> nothing in your small example program from which GCC can infer that those
> >>> two global pointers are in fact 2-aligned.
> >>
> >> So all you'd actually have to say is
> >>
> >> void f1(void)
> >> {
> >> *i; *j;
> >> __builtin_memcpy (i, j, 32);
> >> }
> >
> > No, that doesn't help.
>
> It could do.
>
> > Not even if I make it:
> >
> > void f1(void)
> > {
> > k = *i + *j;
> > __builtin_memcpy (i, j, 4);
> > }
> >
> > The first line does word aligned references to *i and *j, but the memcpy
> > stubbornly remains a byte move.
>
> Right, so that is a missed optimization.
Yes. Note that on GIMPLE alignment of pointers info is carried as
side-info for SSA names
which make the above cases difficult to deal with since the
dereference and the call argument
use the same SSA names. So if you consider
if (i_1 & 7 == 0)
{
k = *i_1;
__builtin_memcpy (i_1, j, 4);
}
then we cannot set the alignment of i_1 at/after k = *i_1 because doing so would
affect the alignment test which we'd then optimize away. We'd need to introduce
a SSA copy to get a new SSA name but that would be optimized away quickly.
So the option would be to change the representation of __builtin_memcpy
either by making it an aggregate assignment or by using a builtin with
explicit alignment or compute alignment at RTL expansion time.
Note the pass that "computes" alignment is currently SSA based (it's
the CCP pass).
Richard.
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
