[PATCH] D114275: [lld-macho] Include Objective-C functions in LC_FUNCTION_STARTS

[Vy Nguyen via Phabricator via llvm-commits]

oontvoo added inline comments.


================
Comment at: lld/MachO/SyntheticSections.cpp:800
+
+  for (const InputFile *file : inputFiles) {
+    if (auto *objFile = dyn_cast<ObjFile>(file)) {
----------------
oontvoo wrote:
> 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 👍 
> > 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

To be frank, chromium is good for most benchmarking purposes - but it isn't quite representative enough for most of our internal apps (for one, it's much smaller). Unfortunately it's the only thing we have public so ... ¯\_(ツ)_/¯


But anyways, I've run your diff on YT and int3 is right that there's negligible difference in link time.


```
x ./LLD_YT_released_base.txt
+ ./LLD_TY_released_diff.txt
    N           Min           Max        Median           Avg        Stddev
x   5         13.33         13.72         13.56        13.534    0.15565989
+   5         13.56         13.92         13.79         13.76    0.15636496
No difference proven at 95.0% confidence
(No diff in CPU/SYS time either)
```

Sorry for the noise here :) 




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114275