[PATCH] D64462: [ADT] [WIP] Add MutableRange class

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D64462#1587661 <https://reviews.llvm.org/D64462#1587661>, @abrachet wrote:

> Thanks, @MaskRay!
>
> > You probably need a data structure to process symbol table/section header table/program header table. To that end, this patch adds an overlay data structure (MutableRange as the name made me puzzled) to make operations more efficient.
>
> The idea here was the llvm-objcopy needs to reference the original sections/symbols etc and that such a data structure could be used to keep both the original and update or add new entries.
>
> > Have you benchmarked whether the librarified llvm-objcopy will benefit from a fancy data structure like this? I'm thinking plain vectors (as is) may just meet the needs.
>
> Not yet. But this can keep the original entries without needing to make a copy of every single one, only the ones that get modified.
>
> > If you just want to make interleaved insertion/deletion efficient
>
> So like cache insertion/deletion and then execute them whenever the data structure is read? Can this be done with std::transform efficiently?
>
> > (MutableRange as the name made me puzzled)
>
> Not married to the name by any means :) Just called such because it creates a mutable layer over an immutable data structure.


Using a overlay data structure for section header table is not necessary. There are not many sections. ~50 is a cap for most applications, so O(N) isn't slow at all. In lld, orphan placement algorithm is quadratic in terms of the number of output sections. This isn't an performance issue at all. I believe ld.bfd has a similar complexity.

Speaking of the dynamic symbol table and the static symbol table. Some shared objects have an awful number of .dynsym entries, e.g. my libclangAST.so has 5000+ .dynsym entries and 7000+ .symtab entries. We do should keep an eye on its performance. IMHO as long as we don't make it O(|syms|^2) it should be fine. It is currently O(|syms| * constant).

After making llvm-objcopy a library, we may do a bunch of operations on it. As I think about it, the operations may look like:

  Objcopy o;
  o.addSymbol();
  o.removeSymbol(); // x100
  o.addSymbol(); // x100
  o.addSection(); // x100
  o.removeSection(); // x100
  o.commit(); // actually perform the operations. Make sure at this point, aggregate the previous operations and do addSymbol() in batch, removeSymbol() in batch, addSection() in batch, and removeSection() in batch.

The time complexity will be just O(|syms|*|types of operations|) instead of O(|syms|*|operations|).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64462/new/

https://reviews.llvm.org/D64462