V3 [PATCH] aarch64: optimized memcpy implementation for thunderx2

[Anton Youdkevitch]

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.