[PATCH] D142747: [Pseudo Probe] Do not instrument EH blocks.

Hongtao Yu via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 27 18:37:14 PST 2023


hoy added inline comments.


================
Comment at: llvm/include/llvm/Analysis/EHUtils.h:17
+/// Compute a list of blocks that are only reachable via EH paths.
+template <typename AccessorTraits, typename FunctionT, typename BlockT>
+static void computeEHOnlyBlocks(FunctionT &F, DenseSet<BlockT *> &EHBlocks) {
----------------
wenlei wrote:
> 1. Is the need for AccessorTraits because of the different API between MBB (member `predecessors()`) vs BB (standalone `predecessors()`)? 
> 
> 2. If we have to use AccessorTraits, can we avoid exposing it as template type at the top level API (`computeEHOnlyBlocks`)? I think we should be able to select the right traits based on BlockT. 
> 
> 3. Since we only need successor/predecessor, I'd suggest we decouple this from `afdo_detail::IRTraits`. That is, we define two small traits here for both MBB and BB.
> Is the need for AccessorTraits because of the different API between MBB (member predecessors()) vs BB (standalone predecessors())?

Yes. I don't see code shared between BB and MBB often. I guess that's one reason preventing it from being shared easily.

> If we have to use AccessorTraits, can we avoid exposing it as template type at the top level API (computeEHOnlyBlocks)? I think we should be able to select the right traits based on BlockT

Can you elaborate a little more? Iike based on typeid check?

> Since we only need successor/predecessor, I'd suggest we decouple this from afdo_detail::IRTraits. That is, we define two small traits here for both MBB and BB.

Makes sense.



================
Comment at: llvm/lib/CodeGen/MachineFunctionSplitter.cpp:90
+static void setDescendantEHBlocksCold(MachineFunction &MF) {
+  struct MIRTraits {
+    static auto getPredecessors(MachineBasicBlock *BB) {
----------------
wenlei wrote:
> As mentioned above, this better be moved into `EHUtils.h`.
I thought about that, but I ended up defining them here because otherwise it'll introduce a cyclic dependency between Analysis and Codegen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142747



More information about the llvm-commits mailing list