AaronBallman wrote: > While working through @nikic's review feedback on the most recent [LLVM-side > PR](https://github.com/llvm/llvm-project/pull/203304), I thought they had a > great > [argument](https://github.com/llvm/llvm-project/pull/203304#discussion_r3404559468) > in favor of separating inlining out from others: > > > @nikic: I think keeping noipa and noinline orthogonal is good. It's > > strictly more expressive than making noipa imply noinline. > > The current LLVM-side design (with inlining controlled separately) also > happens to be similar to GCC's treatment as well. GCC expands the > source-level `__attribute__((noipa))` internally into IR attributes > `noinline`, `noclone`, `noipa`, `no_icf`.
But the documentation in this PR says: > Clang lowers it to LLVM IR's ``noipa`` function attribute and sets the > ```noinline`` function attribute as well, unless always_inline is specified. If it's useful to keep `noipa` orthogonal at the LLVM level, why is it not similarly useful at the Clang level? >From GCC's docs: > This attribute implies noinline, noclone and no_icf attributes. However, this > attribute is not equivalent to a combination of other attributes, because its > purpose is to suppress existing and future optimizations employing > interprocedural analysis, including those that do not have an attribute > suitable for disabling them individually. So it sounds like the GCC feature is basically "never do IPA including things we don't give you control over" and I think we historically have ended up needing to give control over those things, making the lack of orthogonality a design problem (`-ffast-math` is an example of feature that ended up needing precise knobs to control over time). https://github.com/llvm/llvm-project/pull/207502 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
