[PATCH] D100818: [lld-macho] Implement branch-range-extension thunks

Jez Ng via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 7 10:46:29 PDT 2021


int3 added a comment.

I think you haven't uploaded the latest changes



================
Comment at: lld/MachO/Writer.cpp:545
     }
+  } else if (sym != config->entry) {
+    llvm_unreachable("invalid branch target symbol type");
----------------
gkm wrote:
> int3 wrote:
> > why is this `config->entry` check necessary?
> Because of this ...
> ```
> template <class LP> void Writer::run() {
>   prepareBranchTarget(config->entry);
>   . . .
> ```
> ... and this ...
> ```
> bool macho::link(ArrayRef<const char *> argsArr, bool canExitEarly,
>                  raw_ostream &stdoutOS, raw_ostream &stderrOS) {
>   . . .
>   config->entry = symtab->addUndefined(args.getLastArgValue(OPT_e, "_main"),
>                                        /*file=*/nullptr,
>                                        /*isWeakRef=*/false);
>   . . .
> ```
ah. I think it'd make more sense not to call `prepareBranchTarget` with an undefined symbol in the first place...


================
Comment at: lld/MachO/Writer.cpp:564
     prepareBranchTarget(sym);
+    r.isCallSite = true;
+    isec->callSiteCount++;
----------------
gkm wrote:
> int3 wrote:
> > can't we just check for `relocAttrs.hasAttr(RelocAttrBits::BRANCH)` instead of adding a new property on Reloc?
> After seeing your abandoned diff about the performance drag of checking `relocAttrs`, I chose to save the work of doing so again. Perhaps it is a micro-efficiency that I should avoid?
yes please. If you've noticed the theme of my other comments... let's write the simplest code possible first, and optimize it if profile data indicates it's worthwhile :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100818



More information about the llvm-commits mailing list