[PATCH] D141451: [clang] report inlining decisions with -Wattribute-{warning|error}

Nick Desaulniers via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 8 16:15:06 PST 2023


nickdesaulniers added a comment.

In D141451#4100432 <https://reviews.llvm.org/D141451#4100432>, @dblaikie wrote:

> I guess my only other question (worth mentioning in the RFC, perhaps)/direction would be that any of these "things that are expensive but make backend diagnostics better" could be to put them under a different warning flag (if making `-Wattribute-{warning|error}` off by default isn't feasible - leaving them on-by-default but less than great user experience when optimizing code, and have the warning suggest enabling a different warning flag that's more verbose but off by default and also enables the extra location tracking - so codebases that generally do use these attributes can opt in to that, while codebases that generally don't do that don't entirely lose/ignore the attributes).

I don't think it's worth it to try to make these "zero cost."  There are two function attributes here: `__attribute__((error("")))` and `__attribute__((warning("")))`. They are basically implemented precisely the same way except how diagnostics are finally emitted by the frontend:

For `__attribute__((error("")))`, we always emit an error. There is no `-Wno-error=XXX` or `-Wno-XXX` flag to change that. (i.e. no such `-Wattribute-error`)

For `__attribute__((warning("")))`, we emit a warning by default, an error if `-Werror=attribute-warning` is set, and nothing if `-Wno-attribute-warning` is set (unlikely).

Since `-Wno-attribute-warning` is unlikely to ever be set, it's not worth making that case "zero cost."

---

Will work on that RFC though!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141451/new/

https://reviews.llvm.org/D141451



More information about the cfe-commits mailing list