[clang] [clang] Add noipa attribute (PR #207502)
J. Ryan Stinnett via cfe-commits
cfe-commits at lists.llvm.org
Tue Jul 7 08:54:52 PDT 2026
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
More information about the cfe-commits
mailing list