[llvm] r199886 - Prevent repetitive warnings for unrecognized processors and features

[Jim Grosbach]

On Jan 27, 2014, at 9:12 AM, David Blaikie <dblaikie at gmail.com> wrote:

> 
> 
> 
> On Sat, Jan 25, 2014 at 9:33 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> > Our documentation is not very good surrounding some of these larger
> > architectural issues. However, I can tell you with certainty that
> > this patch is unacceptable in it's current state. Revert it.
> >
> > As David said, it violates a fundamental invariant of the LLVM
> > codebase, which is that library users in the same process can
> > independently use the LLVM library. (There are some unfortunate
> > historical deviations from this that are being slowly mended,
> > but going new code doesn't regress on this: it's not up for debate).
> 
> Reverted as r200083, but I'd still appreciate any hints as to what can be an
> acceptable solution to the issue at hand (preventing the same warning from
> being reported multiple times from multiple calling points).
> 
> While Sean and I are trying to provide feedback where we can, at least for myself (and I suspect Sean would agree) we're not necessarily the owners in any of these areas and are by no means an authority to say "this must be reverted" - I appreciate you reverting this to continue discussion.
> 
> It'd probably be helpful if we had someone a little more "owner-y" to comment on how problematic this is, whether there's an obvious alternative, etc. I would guess Jim Grosbach, but not sure if he or others would be most helpful (the usual "how busy are they", "how knowledgable/authoritative are they", etc tradeoffs).

Sounds like this discussion is moving in the right direction already, so I’ll just chime in here briefly to concur that a global variable (or file level or class level static, et. al.) is not an appropriate solution in modern LLVM.

FWIW, the existing code that unilaterally writes out to errs() from deep within the MC layer is also fundamentally broken, to put it mildly.

>  
> If the documentation doesn't guide around these larger architectural issues,
> and the existing code cannot be trusted as an example to follow, then the
> only remaining option I can see is to submit patches at random, until one of
> them gets accepted.
> 
> My naive question would be: what's unique about this argument handling that leads to duplicate error messages here but not for any other argument handling? 

These are backend diagnostics only, right? I.e., they get issued by MC when using developer tools like llvm-mc, llc, et. al.. They’re certainly not diagnostics we would ever expect to see from, e.g., clang or other user-level front-end. As such, I don’t quite follow why we should care about filtering duplicates at all. I don’t oppose uniquing them or anything, I just don’t personally see it as a priority. YMMV.

-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140129/0dbb865f/attachment.html>