melver added a comment. In D104475#2825772 <https://reviews.llvm.org/D104475#2825772>, @nickdesaulniers wrote:
> In D104475#2825711 <https://reviews.llvm.org/D104475#2825711>, @MaskRay wrote: > >> So if we don't want to offer guarantee for IR/C/C++ attributes, we can >> document that users may need to additionally specify >> `__attribute__((noinline))` to suppress inlining. > > I don't generally like that approach: > > 1. it's not easy for developers to validate their call call chains to ensure > that a caller with a restrictive function attribute doesn't have unrestricted > callers inlined into the restricted caller. > 2. that behavior opposes the principle of least surprise. > 3. We don't have a statement attribute for call sites to say "please don't > inline this call" which would be fine grain. noinline is a course-grain > hammer; what if we want to inline a callee into most callers but not this one > caller that has such a restricted function attribute? > > See also D91816 <https://reviews.llvm.org/D91816> where I took the > conservative approach for `no_stack_protector` and simply chose not to > perform such inline substitution on caller and callee function attribute > mismatch. I find this behavior to be the least surprising, and the developer > is provided with introspection as to why the compile did not perform such > inlining via `-Rpass=inline` flag. Agree. I think we just raced to say the same thing. ;-) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D104475/new/ https://reviews.llvm.org/D104475 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
