[PATCH] Fix PR28575.

[Rafael Espíndola via llvm-commits]

New version in https://reviews.llvm.org/D22627

Cheers,
Rafael


On 19 July 2016 at 14:20, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> On 19 July 2016 at 13:34, Rui Ueyama <ruiu at google.com> wrote:
>> On Tue, Jul 19, 2016 at 7:16 AM, Rafael Espíndola
>> <rafael.espindola at gmail.com> wrote:
>>>
>>> > I think you want to remove "That means ..." part because it doesn't
>>> > describe the behavior of this function.
>>>
>>> Done.
>>>
>>> > Why don't you store relocation indices to section pieces? It would be
>>> > better than having parallel arrays.
>>>
>>> The common use is for SHF_MERGE sections that don't have relocations.
>>> The existing code is trying to pack it to be cache friendly (uses
>>> bitfield).
>>>
>>> I could just remove SplitInputSection and have MergeInputSection and
>>> EhInputSection declare their own Pieces array. The one in
>>> EhInputSection would have the first relocation of each piece. What do
>>> you think?
>>
>>
>> Because of my previous change to use a hash table rather than doing binary
>> search, I think cache friendliness of SectionPiece is now less important. So
>> you may just want to add a new field. You may want to benchmark?
>
>
> Good point. I will give it a try.
>
> Cheers,
> Rafael