[PATCH] D16468: [ELF] - Attempt to simplify the relocations relaxation code
Rafael Espíndola via llvm-commits
llvm-commits at lists.llvm.org
Tue Jan 26 14:27:54 PST 2016
So, I like the general idea of saving info during reloc scan that is
then used for reloc application and/or writing dynamic relocations. It
is a bit similar to what I did for .dynamic.
I do have the same concerns as Rui for the current patch. Out of
curiosity, have you tried going all the way and just storing *all* the
information needed to perform a relocation?
On 23 January 2016 at 06:25, George Rimar <grimar at accesssoftek.com> wrote:
> grimar added inline comments.
> Comment at: ELF/InputSection.h:91
> @@ +90,3 @@
> + const Elf_Shdr *Sec = nullptr;
> + std::vector<RelocData> Relocs;
> + };
> ruiu wrote:
>> Is this a bitmap where each bit at position n represents whether or not n'th relocation in `Sec` needs a TLS optimization? If so, I doesn't feel like a clean design. Having side data is somewhat confusing. I'm sorry that I don't have a counter suggestion here, but it feels like this change is somewhat neutral from the readability point of view.
> Yes it was such a bitmap. In current situation it helps to avoid multiple isTlsOptimized calls what IMO makes situation better overall.
> I dont like idea to keep additional data but I also dont feel it very bad. We also can probably add more fields there to calculate it only one time during first scan, like needsGot flag for example.
> So I abandoned it for now but if there is something I can do with it to land it please let me know.
More information about the llvm-commits