[PATCH] D114275: [lld-macho] Include Objective-C functions in LC_FUNCTION_STARTS
Vy Nguyen via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Sat Nov 20 09:23:04 PST 2021
oontvoo added inline comments.
================
Comment at: lld/MachO/SyntheticSections.cpp:800-813
+ for (const InputFile *file : inputFiles) {
+ if (auto *objFile = dyn_cast<ObjFile>(file)) {
+ for (const Symbol *sym : objFile->symbols) {
+ if (const auto *defined = dyn_cast_or_null<Defined>(sym)) {
+ if (!defined->isec || !isCodeSection(defined->isec) ||
+ !defined->isLive())
+ continue;
----------------
int3 wrote:
> int3 wrote:
> > int3 wrote:
> > > thevinster wrote:
> > > > keith wrote:
> > > > > oontvoo wrote:
> > > > > > keith wrote:
> > > > > > > oontvoo wrote:
> > > > > > > > Do you happen to have performance data for this change?
> > > > > > > > seems like it could take a hit here , esp. for cases where the number of input files is large - ie., most of our apps :)
> > > > > > > >
> > > > > > > > On the other hand, I agree debug experience is important...
> > > > > > > >
> > > > > > > I've haven't tested this on our large links yet so I'll have to check, I agree, I felt bad writing this
> > > > > > How would people feel about making this configurable? ( either via making up some new flag or grouping it into an existing one)
> > > > > Maybe -no-function-starts is enough for this level of configuration? We actually have that enabled today for our builds for binary size.
> > > > Hmm... I think we can parallelize this. This might offset the need to gate it behind a flag. Although, we can hold off on this until more concrete data on how bad this affects the link speed.
> > > >
> > > > Why can't we add these symbols to the symtab?
> > > > Why can't we add these symbols to the symtab?
> > >
> > > the symtab is for global (aka extern) symbols, which need to have unique names across all object files. local symbols do not have that constraint.
> > >
> > > Anyway, this is being done in parallel with other stuff (see `finalizeLinkEditSegment()`), so its perf impact might actually be negligible in practice
> > I would prefer we not add too many config flags. I'm also not sure there's much value in having partially emitted debug info -- I figure you either want or don't want it. `-no-function-starts` is probably enough for now.
> > I've haven't tested this on our large links yet
>
> We've been using chromium_framework as an ad-hoc benchmark, since it's something that all of us can repro: https://bugs.llvm.org/show_bug.cgi?id=48657#c0
>
> Would be nice to include some numbers for that in the commit message. For running the benchmark, I like to use https://github.com/asayers/cbdr/blob/master/cbdr.md
>
> My usual invocation is `cbdr sample "base:~/bench-base/ld64.lld @response.txt" "diff:~/bench-diff/ld64.lld @response.txt" --timeout=300s | tee results.csv | cbdr analyze -s 95`
SG 👍
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D114275/new/
https://reviews.llvm.org/D114275
More information about the llvm-commits
mailing list