Re: V3 [PATCH] aarch64: optimized memcpy implementation for thunderx2

[Anton Youdkevitch <anton dot youdkevitch at bell-sw dot com>]

On 11.10.2018 19:23, Richard Earnshaw (lists) wrote:
> On 11/10/18 17:16, Anton Youdkevitch wrote:
> > On 11.10.2018 17:34, Richard Henderson wrote:
> > > On 10/11/18 6:32 AM, Anton Youdkevitch wrote:
> > > > > be unmeasurable compared to the load.  I do suggest you use
> > > > > properly pc-relative addresses in that case though.
> > > > > I.e. "L(foo) - .".
> > > > Now I do not follow. Why is the existing addressing is a not
> > > > proper pc-relative one except for the part that it employs
> > > > the fact that the distance is small and adrp is not needed?
> > > > Or this is what you actually meant?
> > >
> > > I suppose it doesn't matter, now that I write it out and count
> > > instructions,
> > > but it would be the difference between
> > >
> > >      adrp    tmp2, L(ext_table)
> > >      add    tmp2, tmp2, :lo12:L(ext_table)
> > >      ldr    tmp2, [tmp2, tmp1, LSL #3]
> > >      adr    tmp3, L(load_and_merge)
> > >      add    tmp2, tmp2, tmp3
> > >      br    tmp2
> > >
> > > and
> > >
> > >      adrp    tmp2, L(ext_table)
> > >      add    tmp2, tmp2, :lo12:L(ext_table)
> > >      add    tmp2, tmp1, LSL #3
> > >      ldr    tmp3, [tmp2]
> > >      add    tmp2, tmp2, tmp3
> > >      br    tmp2
> > >
> > > If you're going to subtract L(load_and_merge), you might even save
> > > memory by
> > > noting that the displacements fit in bytes instead of quads.
> > But isn't it a matter of clarity now? I mean, unless we really
> > care of additional ~100 bytes this is more important.
> >
> >
> > > > Also, the "dot" cannot be used for for cross-section address
> > > > generation.
> > >
> > > Absolutely it can.  It is in fact exactly R_AARCH64_PREL64.
> > Oh... And the linker will fix the relocations in the resulting
> > (shared) library? OK then.
>
> If you need to fix a PC-relative reference inside a shared library,
> you've probably done something wrong.  PC-relative should normally be
> resolved at static link time.  That's possible if both sections will end
> up in the same shared library due to the way that the relative placement
> of the sections becomes fixed at that point.
Yes, this is what I was missing. Since both sections are to be placed
into the same library the relocations will be resolved only once at link
time.

Thanks a lot for the comments and the explanations. I will resend the
patch as soon as the testing finishes.