[PATCH] D91803: [lld] Use -1 as tombstone value for discarded code ranges

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 20 13:40:15 PST 2020


sbc100 added inline comments.


================
Comment at: lld/wasm/InputChunks.h:230
   const WasmSection §ion;
+  const uint64_t tombstone_value;
 };
----------------
MaskRay wrote:
> sbc100 wrote:
> > MaskRay wrote:
> > > sbc100 wrote:
> > > > We use the lowerCamel style so I think this should be tombstoneValue?
> > > Is the space consumption a concern? 
> > I not been to concerted about adding data O(input chunk).   Honestly, we have not done much in the way optimizing wasm-ld for speed or memory consumption.   Rui often guided me to keep the symbol size down and to avoid per-symbol hash lookup.. but per-input-chunk data I've not been too concerned about.
> > 
> > I guess one alternative would be to store a tombstone-type enum with three possible values?   
> The sizes of SymbolUnion and InputSections are important for the ELF's port.
> 
> As an example, the basic block sections feature cost us more than 1% peak memory usage. D91018 claimed back 0.6%
Point taken.   And since wasm mandates `-ffunction-sections` and `-fdata-sections` is the default we are even more effected than ELF by default I guess.

I'm embarrassed to say I have done zero benchmarking of wasm-ld thus far.


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

https://reviews.llvm.org/D91803



More information about the llvm-commits mailing list