Details
- Reviewers
pcc mehdi_amini
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
55 | How do you prevent duplicate? |
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
55 | findLibCallsAndAsm is the only function that adds globals to LLVMUsed. The only call sites are in findInModule which cannot pass duplicates. We can easily change findLibCallsAndAsm to add the global at most once. |
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
55 | But this is "updating" the list, so even if findLibCallsAndAsm adds the globals at most once, they can already be in the list, what did I miss? |
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
55 | The only user start with an empty list. |
lib/Transforms/Utils/ModuleUtils.cpp | ||
---|---|---|
104 | We'll end up with duplicates. This is how the current code works. Btw, is not SmallPtrSet unstable in the "large mode", when it is backed by hash table? Do we not care about the order of llvm.used entries being stable? |
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
117 | Now I may be missing something, but this set is converted to a vector before the current llvm.compiler.used is read. There is now deduplication between the current entries of llvm.compiler.used and the new elements. And, as Peter explained above, the new elements are unique among themselves. |
lib/LTO/UpdateCompilerUsed.cpp | ||
---|---|---|
117 | You're right. However it is a bug I introduced when refactoring this in http://reviews.llvm.org/D19000 ; the original code was turned the set into a vector only after appending the existing elements. So we should fix this bug and not simplify the code assuming the buggy behavior is expected. |
This could be a std::vector.