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

[Di Mo via Phabricator via llvm-commits]

modimo added a comment.

In D142747#4087141 <https://reviews.llvm.org/D142747#4087141>, @wenlei wrote:

> In D142747#4087114 <https://reviews.llvm.org/D142747#4087114>, @hoy wrote:
>
>> In D142747#4087112 <https://reviews.llvm.org/D142747#4087112>, @modimo wrote:
>>
>>> In D142747#4087088 <https://reviews.llvm.org/D142747#4087088>, @modimo wrote:
>>>
>>>> In D142747#4087069 <https://reviews.llvm.org/D142747#4087069>, @wenlei wrote:
>>>>
>>>>> In D142747#4086978 <https://reviews.llvm.org/D142747#4086978>, @modimo wrote:
>>>>>
>>>>>> We've got the same EH-ness propagation code in MFS already: https://reviews.llvm.org/D131824. Consider merging the code?
>>>>>
>>>>> That diff also used EHPad as seeds for BFS, I thought we only need LandingPads as seeds? Though I think for simple algorithm, having MIR and IR implementation separated is probably fine. I also don't know where to put a merged version..
>>>>>
>>>>>   if (MBB.isEHPad())
>>>>>     LandingPads.push_back(&MBB);
>>>>
>>>> LandingPads are the only thing that exists for x86_64 Linux while `catchswitch`, `catchpad`, and `cleanuppad` are all for Windows EH (https://llvm.org/docs/ExceptionHandling.html#new-exception-handling-instructions). Without proper testing on Windows I'd advocate for keeping it to LandingPads only.
>>>
>>> For where to put it, right now I'd say there's not a good place for it and we may want to create a new file. Clang has `llvm-project/clang/lib/CodeGen/CGException.cpp` for all of it's EH support structure but EH on LLVM is very haphazard (I suspect because outside of correctness there was not much optimization thought put into it).
>>>
>>> I would support adding a `llvm/lib/Analysis/Exceptions.cpp` (or whatever name makes sense) like `llvm/lib/Analysis/EHPersonalities.cpp` exists. Otherwise, if we don't want to add another file I would place it in `Function.h/cpp` since technically we can consider this calculating a property of the function.
>>
>> I'm thinking about llvm/include/llvm/Analysis/CFG.h as a place to put the templated code. WDTY?
>
> No, clearly CFG.h operates on a different abstraction level that is unaware of high level concepts like EH. I think we should keep it that way..
>
>> I would support adding a llvm/lib/Analysis/Exceptions.cpp (or whatever name makes sense) like llvm/lib/Analysis/EHPersonalities.cpp exists. Otherwise, if we don't want to add another file I would place it in Function.h/cpp since technically we can consider this calculating a property of the function.
>
> I'm not sure this is useful enough to be part of core IR constructs like function/basicblock. Adding its own file seems like a better place than any of the existing ones, though just for one not commonly used function.. That's why I say I don't know :)

I'm not confident on what exactly is the right thing to do here either. Looking through the code base we've got other code that could fit better in a `llvm/lib/Analysis/Exceptions.cpp` like https://github.com/llvm/llvm-project/blame/main/llvm/lib/CodeGen/Analysis.cpp#L729. Looks like Analysis.cpp is a dumping ground for functions that don't fit elsewhere which is another ref-count to me that a dedicated file for EH makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142747