[llvm-dev] RFC: LLD symbol table redesign

[Peter Collingbourne via llvm-dev]

On Wed, Apr 27, 2016 at 3:58 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > A sketch of how the symbol table might implement adding an undefined
> symbol:
> >
> > Symbol *SymbolTable<ELFT>::addUndefined(StringRef Name, uint8_t Binding,
> …)
> > {
> >   std::pair<Symbol *, bool> P = insert(Name);
> >   if (!P.second) { // symbol already in symbol table
> >     if (auto *L = dyn_cast<Lazy>(P.first->body()))
> >       addFile(L);
> >     return P.first;
> >   }
> >   // symbol previously unseen
> >   new (P.first->Body) Undefined(Name, Binding, ...);
> >   return P.first;
> > }
> >
> > Input files would have an associated symbol list for use in resolving
> > relocations. This symbol list would be a std::vector<Symbol *>. Symbols
> > retrieved from the symbol table are added to the symbol list. Relocations
> > would be resolved by following two fewer levels of indirection, from the
> > vector to the Symbol, rather than the current vector -> SymbolBody ->
> Symbol
> > -> SymbolBody.
>
> I do like the design. What are you doing with local symbols? Are they
> just an special symbol type?
>

I'm not sure, but I think the best approach may be to process them directly
in the Writer without creating Symbols for them. This may help us save time
in file parsing because (according to Rui) most symbols are not global
symbols.

Another thing that can be tried that might be simpler and already
> provide some performance advantage:
>
> * Replace the current map vector. We have a map to an symbol number
> that indexes an array. We could map directly to a Symbol if:
>   * We stored the number in the Symbol to allow sorting.
>   * Or used a hash that produces the same value everywhere.
>

Thanks, I might try that as well. The second one should be quite easy to
benchmark without needing a stable hash.

Thanks,
-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/1f2da7fc/attachment.html>