This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Use llvm ADT's instead of std.
Needs ReviewPublic

Authored by shankarke on Feb 25 2015, 10:13 AM.

Details

Reviewers
ruiu
Bigcheese
Summary

This changes usage of std::map/std::unordered_map to use llvm ADT's. The llvm ADT's are more light weight, easy to use,
there are more error checks and easier to debug if there is an issue. Makes it consistent with rest of llvm too.

This change otherwise doesnot bring any new functionality.

Diff Detail

Event Timeline

shankarke updated this revision to Diff 20688.Feb 25 2015, 10:13 AM
shankarke retitled this revision from to [ELF] Use llvm ADT's instead of std..
shankarke updated this object.
shankarke edited the test plan for this revision. (Show Details)
shankarke added reviewers: Bigcheese, ruiu, atanasyan.
shankarke added a project: lld.
shankarke added a subscriber: Unknown Object (MLST).
atanasyan added inline comments.Feb 25 2015, 10:54 AM
lib/ReaderWriter/ELF/DefaultLayout.h
120

Why do you drop this comment?

davide added a subscriber: davide.Feb 25 2015, 11:19 AM

I skimmed over the patch quickly and it seems good to me. I'm curious to know if you made any A/B comparison, and if LLVM ADT results faster for this particular use case.

rnk added a subscriber: rnk.Feb 25 2015, 11:31 AM

Rui mentioned that he had to change a DenseMap to a std::map / unordered_map to fix a crasher when linking Chrome. Unfortunately, I don't think he ever figured exactly what was wrong with the LLVM container.

Unfortunately, the Chrome link is currently broken, or I would tell you to watch the bot when you commit:
http://build.chromium.org/p/chromium.fyi/builders/CrWinClangLLD

shankarke added inline comments.Feb 25 2015, 11:41 AM
lib/ReaderWriter/ELF/DefaultLayout.h
120

Good catch, will put those comments back,

davide: I havent measured. There are some low hanging fruits which I plan to do of resizing certain maps.

rnk : I was able to self-host clang/lld and run without any issues, and I would think he was trying to link chromium with the lld windows flavor.

shankarke updated this revision to Diff 20692.Feb 25 2015, 11:51 AM

Address comments from Simon.

ruiu edited edge metadata.Feb 25 2015, 12:26 PM

I usually don't apply someone else's patch to test Chromium build, but this should not affect the Windows port anyway, because this only changes the ELF port.

But this change may be riskier than you might think because of the subtle difference of semantics between std::map and llvm::DenseMap regarding references returned by operator[] and iterators. For std::map, it is guaranteed that inserting a new element does not invalidate existing references to a std::map. It doesn't invalidate iterators unless you remove an element and an iterator is pointing to the element.

These properties are not guaranteed by DenseMap. So, if you add a new item to a map while you are iterating over elements of the map, it may crash. It actually crashes only when the hash table is resized to add a new element for LHS, so it could produce a nasty flaky bug. For example the bug in the LayoutPass was there for more than 1 year until I fixed that.

Even

m[x] = m[y]

is not guaranteed to be safe for a DenseMap m, because a reference returned by m[y] can be invalidated by m[x]. This particular one is the bug in LayoutPass.cpp that Reid mentioned above (fix is r213969).

I checked the code quickly, and it looks safe to me, but please review your patch again with the above thing in your mind.

Thanks for the info, Rui. Adding items to the map while you are iterating is bad in the first place, not sure why std::map didnt show the issue. I will double check the ELF Reader/Writer for any of these occurences.

sanjoy added a subscriber: sanjoy.Feb 25 2015, 1:06 PM

These properties are not guaranteed by DenseMap. So, if you add a new item to a map while you are iterating over elements of the map, it may crash. It actually crashes only when the hash table is resized to add a new element for LHS, so it could produce a nasty flaky bug. For example the bug in the LayoutPass was there for more than 1 year until I fixed that.

A slight tangent: do you guys think it will be worth the effort to
turn such errors to deterministically fail an assert in debug mode?
For instance, I can imagine having an "epoch" counter in the DenseMap
and DenseMapIterator, with modifications to the DenseMap bumping the
counter and iterator accesses asserting "ParentDenseMap->epoch ==
this->epoch" on access.

Even

m[x] = m[y]

is not guaranteed to be safe for a DenseMap m, because a reference returned by m[y] can be invalidated by m[x]. This particular one is the bug in LayoutPass.cpp that Reid mentioned above (fix is r213969).

I checked the code quickly, and it looks safe to me, but please review your patch again with the above thing in your mind.

http://reviews.llvm.org/D7885

EMAIL PREFERENCES

http://reviews.llvm.org/settings/panel/emailpreferences/

llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

atanasyan resigned from this revision.Feb 3 2016, 12:43 AM
atanasyan removed a reviewer: atanasyan.