[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.

In D83906#4182476 <https://reviews.llvm.org/D83906#4182476>, @dexonsmith wrote:

> In D83906#4182428 <https://reviews.llvm.org/D83906#4182428>, @hoy wrote:
>
>> In D83906#4182287 <https://reviews.llvm.org/D83906#4182287>, @dexonsmith wrote:
>>
>>> In C++, you get linkonce_odr all over the place. It's basically all functions that are defined in C++ headers that are available for inlining.
>>
>>
>>
>>> On the other hand, the frontend knows the token sequence from the source language. It knows whether function B is inherently nounwind based on its ODR token sequence; in which case, it's safe to use the attribute for an IPA peephole.
>>
>> Thanks for the detailed explanation again! As you pointed out previously, linkonce_odr is something the front end can optimize. I'm wondering why the front end is confident about that the linker would not replace the current definition with something else.
>
> The frontend has generated unrefined IR with all side effects from the must-be-ODR-equivalent source still present. It's not until on optimizer gets at it that side effects can be refined away. (Unless the IRGen peepholes are powerful enough to refine away side effects, but I don't believe IRGen does that.)
>
> Since the IR from IRGen is unrefined (still has all side effects present in the source), whatever the linker/loader chooses cannot gain "extra" side effects through de-refinement.

As far as I know, the optimizer IPO pass that infers function attributes (i..e `InferFunctionAttrsPass`) is placed at the very beginning of the optimization pipeline.  Does this sound to you that the side effects computed for linkonce_odr functions there can be trusted by the rest of the pipeline?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83906