If a traced symbol is not inserted at all, a placeholder symbol
remains in the symbol table, but that's OK. For the parallel symbol
resolution, I'm planning to insert lots of placeholder symbols which
will remain as placeholder symbols after symbol resolution.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lld/ELF/Driver.cpp | ||
---|---|---|
1403 ↗ | (On Diff #201208) | I am thinking about using llvm iterators for example. Just do not sure that spreading !S->isPlaceholder() around looks fine. |
lld/ELF/Driver.cpp | ||
---|---|---|
1403 ↗ | (On Diff #201208) | Something like getNonPlaceholderSymbols() based on llvm::make_filter_range? |
lld/ELF/Driver.cpp | ||
---|---|---|
1403 ↗ | (On Diff #201208) | make_filter_range should work, but if we use the function, getSymbols's function signature would be complicated, so I decided to use a lambda instead. How does this look? |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | llvm::function_ref should probably be a bit better, btw. |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | I didn't take a look at the assembly, but isn't this something that a compiler can optimize and erases std::function? Since this is an inline function, a compiler knows exactly how a given lambda is used. |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | I do not know the answer. |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | function_ref should be better, but I don't know if compilers can optimize out the heap allocation used for the lambda. I still want to understand how complicated the signature of llvm::make_filter_range is. Let me check |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | struct FilterOutPlaceholder { bool operator()(Symbol *S) const { return !S->isPlaceholder(); } }; static iterator_range<filter_iterator<std::vector<Symbol *>::iterator, FilterOutPlaceholder>> symbols() { return make_filter_range(Symtab->SymVector, FilterOutPlaceholder()); } The benefit is that the backtrace will be simpler in a debugger. |
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | We can do that too, but it seems a bit more complicated than the lambda. I'm also making a change to split SymVector and SymMap into multiple shards for parallel name resolution. With that, the iterator would have more complicated type, as you need to concatenate multiple iterators and then filter out some members after that. |
- Change the callback object type from std:function to llvm::function_ref. Looks like Clang can eliminate a given lambda and inline it if we take it as a llvm::function_ref.
lld/ELF/SymbolTable.h | ||
---|---|---|
38 ↗ | (On Diff #201476) | Since you plan to split SymVector, a linear for look no longer works in call sites, this looks good to me, otherwise I would still think the for (auto xxx : SymTable->symbols()) ... is better than Symtab->forEachSymbol([](Symbol *Sym) { ... }); |