[PATCH] D118177: [llvm-profgen] Decouple artificial branch from LBR parser and fix external address related issues

Hongtao Yu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 25 17:00:40 PDT 2022


hoy added inline comments.


================
Comment at: llvm/tools/llvm-profgen/PerfReader.h:488
+        Binary->getCallAddrFromFrameAddr(State.getCurrentLBRTarget());
+    return (CallAddr != 0);
+  }
----------------
wlei wrote:
> hoy wrote:
> > Is this detecting a general return or just return from external?
> This is a heuristic to only detect returning from external because the source is external(unknown), so we leverage target address checking if it's the next inst of call inst.
> 
> For the general return, the source is known, so we use `addressIsReturn` to determine if it's a return.
I meant to say the name of this function doesn't exactly match its code. Maybe including the `isSourceExternal` check in this function?


================
Comment at: llvm/tools/llvm-profgen/PerfReader.h:514
+    // Check if the return source is from external code.
+    return isSourceExternal(State) && isReturnFromExternal(State);
   }
----------------
wlei wrote:
> hoy wrote:
> > Can we have an internal-to-external return here? I'm wondering if it should be filtered out.
> The  internal-to-external return pattern is handled by the right above branch(`if (Binary->addressIsReturn(State.getCurrentLBRSource()))`) which checking the source if it's a return.
Ok, a return to external is considered as a return. But in `unwindReturn`, the pushing external frame code is being removed. Should we keep it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118177



More information about the llvm-commits mailing list