dexonsmith added a comment. 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83906/new/ https://reviews.llvm.org/D83906 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
