jryans wrote: > There was previous discussion on this in > [discourse.llvm.org/t/revisiting-refining-the-definition-of-optnone-with-interprocedural-transformations/58095/11](https://discourse.llvm.org/t/revisiting-refining-the-definition-of-optnone-with-interprocedural-transformations/58095/11) > and I think there was maybe enough push back to warrant a new RFC to ensure > everyone is on the same page regarding the design, particularly regarding > whether this implies noinline or not. However, CCing folks involved there for > opinions in case we think we can avoid an RFC: @jdoerfert @dwblaikie
There were also further rounds of previous discussion, both in an earlier [patch](https://reviews.llvm.org/D101011) (2021) and on the [forum](https://discourse.llvm.org/t/noipa-continues/74411) (2023). 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`. https://github.com/llvm/llvm-project/pull/207502 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
