This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Attempt to simplify the relocations relaxation code
AbandonedPublic

Authored by grimar on Jan 22 2016, 9:56 AM.

Details

Reviewers
ruiu
rafael
Summary

This patch introduces the next changes:

  1. During Writer<ELFT>::scanRelocs() marks and remembers for each relocation if it can be optimized(relaxed) or not.
  2. In following code remembered values are used. (RelocationSection<ELFT>::writeTo() is not covered yet, it is possible to make it use remembered values also, If this patch will be ok, I`ll do that).
  3. InputSectionBase<ELFT>::relocate() is split to relocateNotOptimized and relocateOptimized. So relaxations are handled separately what also simplified the code.

All above allowed to significantly reduce amount excessive isTlsOptimized calls (after fixing p2 which has one, the only places will be in Target class, what is fine and expected I believe).
I introduced

struct RelocData {
   bool Optimized = false;
 };

struct for each relocation data, but It looks single boolean is enough now and I can replace the struct with single bool. Not sure will we need to remember any other data for relocations ?

Diff Detail

Event Timeline

grimar updated this revision to Diff 45694.Jan 22 2016, 9:56 AM
grimar retitled this revision from to [ELF] - Attempt to simplificate the relocations relaxation code.
grimar updated this object.
grimar added reviewers: ruiu, rafael.
grimar added subscribers: llvm-commits, grimar.
grimar retitled this revision from [ELF] - Attempt to simplificate the relocations relaxation code to [ELF] - Attempt to simplify the relocations relaxation code.Jan 22 2016, 10:00 AM
grimar updated this object.
ruiu added inline comments.Jan 22 2016, 10:32 AM
ELF/InputSection.h
85–87

Why do you need a struct that has only one member?

91

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.

ELF/Writer.cpp
243–245

Please keep this code here. If you can eliminate data early in a process, do early there rather than later.

grimar abandoned this revision.Jan 22 2016, 2:08 PM

I will wait to see better solution. I am sure it exist.

ELF/InputSection.h
85–87

Please read patch notes, I am not sure will we need any additional data or not. So it is easy to replace it with single bool.

grimar added inline comments.Jan 23 2016, 6:25 AM
ELF/InputSection.h
91

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.

rafael edited edge metadata.Jan 26 2016, 2:27 PM
rafael added a subscriber: rafael.

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?

Cheers,
Rafael

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?

Cheers,
Rafael

No, I didn't try to store anything except "Optimized" field yet. To do that it would probably better to perform additional pass/write separate function to get all information in one special place. It sounds as a change to current design and I think at first we should decide do we find the idea to store such amount of additional data acceptable or not.
Personally I would be happy to resurrect this patch and try to do that.