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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
