This is an archive of the discontinued LLVM Phabricator instance.

LLD: Use std::vector to store SimpleReferences instead of linked list.
Needs ReviewPublic

Authored by ruiu on Mar 9 2015, 1:54 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

Previously, SimpleReferences has two pointers to previous and next references,
making them elements of linked lists. I don't know how this design choice was
made, but it looks like we can just use plain std::vector instead of std::ilist.
Performance-wise this patch is neutral.

Diff Detail

Event Timeline

ruiu updated this revision to Diff 21509.Mar 9 2015, 1:54 PM
ruiu retitled this revision from to LLD: Use std::vector to store SimpleReferences instead of linked list..
ruiu updated this object.
ruiu edited the test plan for this revision. (Show Details)
ruiu added a project: lld.
ruiu added a subscriber: Unknown Object (MLST).

SimpleReference was implemented using a vector not so long ago, but that design choice was made because std::vector is not bumpPtrAllocator friendly.
Mach-O implementation (at least) uses a bumpPtrAllocator to allocate the SimpleReferences. So SimpleReference destructor is never call, and so are members destructor.
If you use a std::vector, it means you will leak the vector storage memory. As all ilist nodes are allocated using the bumpPtr allocator, we don’t have that issue.

ruiu added a comment.Mar 9 2015, 9:55 PM

Where is the code? Looks like SimpleReference is used only by PE/COFF port.

This may mean we need teach SmallVector to accept allocator like other ADT.

ruiu added a comment.Mar 15 2015, 11:08 PM

I think SmallVector guarantees the array it contains is contiguous in
memory. That data structure does not work well with BumpPtrAllocator
because garbage after extending the array is not reclaimed until the whole
buffer is discarded. That makes memory consumption of a small vector from
O(n) to O(n^2).

That being said, that behavior might be acceptable if we rarely extend
SmallVectors. So, maybe it's not a bad idea, but I don't know if it's good
enough to add an additional parameter to SmallVector's constructor.