[PATCH] D61710: lld: Add a warning limit, similar to the existing error limit

Alexander Richardson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 9 01:35:29 PDT 2019


arichardson added a comment.

In D61710#1496112 <https://reviews.llvm.org/D61710#1496112>, @ruiu wrote:

> In D61710#1496097 <https://reviews.llvm.org/D61710#1496097>, @arichardson wrote:
>
> > I implemented the same thing for the CHERI fork of lld since I added some new warning that could in certain cases be emitted many times but are not necessarily a real problem.
>
>
> What would you do if something is not a real problem? I'd think "fix all warning" is generally a good idea, so I'd try to fix the problem (if it is not a real problem) or suppress the warning, and when suppressing a warning, I'd do one by one. So I wouldn't personally suppress warnings as a whole, as it could hide other warnings.


I agree and we do try to fix all of these. However, it may take a while to update all the cases where this is triggered in CheriBSD and I don't want to flood the build log with hundreds of almost identical warnings since it makes it harder to find the real issue. In the past this was a bigger problem since everything was very experimental and constantly changing. Now things are a lot more stable and we rarely add new warnings that cause this warning limit to be reached.

> I just came up with another (maybe crazy) idea. When we get an overwhelming number of warnings, they are usually of the same kind of warning. So, it might make sense to set a limit per a warning. And there's an easy (and probably a bit hacky) way to do that -- we can identify who calls `warn()` by an address returned by `__builtin_return_address()`. If some line invokes `warn()` more than a certain threshold (e.g. 20), we can immediately return from `warn()`.

I think this should work (as long as we don't end up with helper functions that call `warn` and therefore hide the real caller).
Having a limit per-warning rather than a global limit would allow retaining useful warnings while limititing the identical ones than can (at least temporarily) be ignored.
Another solution would be to change warnings that can be emitted many time times to use a `warnLimited` or similar function but that would require analyzing all `warn` calls.
I like the idea with the return address.


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

https://reviews.llvm.org/D61710





More information about the llvm-commits mailing list