This is an archive of the discontinued LLVM Phabricator instance.

[lld-macho][nfc] Minor clean up
Needs RevisionPublic

Authored by oontvoo on Feb 3 2022, 8:47 AM.

Details

Reviewers
int3
Group Reviewers
Restricted Project
Summary
  • change the vector of relocs to std::list for ptr stability. (This field does not need to have fast access per index anyway. This should also make the remove/erase ops faster)
  • when checking for entry existance use, .find() rather than the [] operator, which would actually create a new entry in the map.

Diff Detail

Event Timeline

oontvoo created this revision.Feb 3 2022, 8:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2022, 8:47 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
oontvoo requested review of this revision.Feb 3 2022, 8:47 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 3 2022, 8:47 AM
oontvoo edited the summary of this revision. (Show Details)Feb 3 2022, 8:48 AM
oontvoo edited the summary of this revision. (Show Details)
smeenai added a subscriber: smeenai.Feb 3 2022, 9:00 AM

I'm wary about using linked lists, especially for relocations ... could you measure the perf and memory usage difference from that? (Maybe each subsection has few enough relocations that it doesn't make a massive difference, but I'm still curious.)

If pointer stability is the main motivation, would std::deque work?

int3 added a subscriber: int3.Feb 3 2022, 9:48 AM

The list change is def a bit more controversial. I would split out the map changes into its own diff :)

Also, could you elaborate on where you anticipate needing pointer stability?

Finally, if we really need a list, we might want to use LLVM's ilist for better locality.

int3 requested changes to this revision.Mar 10 2022, 8:32 PM

clearing my queue

This revision now requires changes to proceed.Mar 10 2022, 8:32 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 10 2022, 8:32 PM