dblaikie added a comment. > In D68410#1696411 <https://reviews.llvm.org/D68410#1696411>, @joerg wrote: > >> I wonder if we should actually enumerate evil here, i.e. give the situations >> in which inlining actually fails. > > > Which is likely to change over time. I worry that enumerating such cases is > compiler version specific, and might lead to developers depending/[ab]using > that behavior?
I'm jumping in part-way here, but FWIW I'd be concerned that the lack of explicit rules is actually going to make people depend on the whims of the optimizer/inliner - if we have a backend warning that only fires when inlining doesn't occur. So narrowing the set of cases we accept in the frontend seems like it reduces the risk of abuse by compiler users - leaving more freedom for the compiler optimizations to change without breaking existing code. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68410/new/ https://reviews.llvm.org/D68410 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
