[lld] r254461 - [ELF] MIPS paired R_MIPS_HI16/LO16 relocations support

[Simon Atanasyan via llvm-commits]

On Wed, Dec 2, 2015 at 12:51 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Simon Atanasyan via llvm-commits" <llvm-commits at lists.llvm.org>
>> To: llvm-commits at lists.llvm.org
>> Sent: Tuesday, December 1, 2015 3:24:46 PM
>> Subject: [lld] r254461 - [ELF] MIPS paired R_MIPS_HI16/LO16 relocations support
>>
>> Author: atanasyan
>> Date: Tue Dec  1 15:24:45 2015
>> New Revision: 254461
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=254461&view=rev
>> Log:
>> [ELF] MIPS paired R_MIPS_HI16/LO16 relocations support

[...]

> If I'm reading this correctly, this search is O(N^2/2) in the worst case.
> Is there some reason you don't get that behavior in practice?
>
> It seems like if we presorted a list by <type, offset>, we could easily
> make this O(N*ln(N)) instead.

Usually a distance between R_MIPS_HI16 and corresponding R_MIPS_LO16
relocation are 1-3 steps. So for each R_MIPS_HI16 relocation we need
to check a few next entries in a relocation list. If think a cost of
building and maintaining complete sorted relocations list is much
higher than this lookup.

There is one more method of handling R_MIPS_HI16/LO16 pairs. We can
save R_MIPS_HI16 relocations in a container and postpone calculation
When we get R_MIPS_LO16 relocation, we iterate over the list and handle
all postponed HI16 relocations. This method does not require lookup
at all. But in this case it might be difficult to organize relocations
handling in parallel.

I am going to return to this point of the code later, measure performance
of various approaches on a real data and select the best variant.

-- 
Simon Atanasyan