[clang] [clang] Add noipa attribute (PR #207502)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Wed Jul 8 08:46:40 PDT 2026
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
More information about the cfe-commits
mailing list