[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