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

David Blaikie dblaikie at gmail.com
Mon Jan 27 09:12:21 PST 2014


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).


> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140127/df5f3bf8/attachment.html>


More information about the llvm-commits mailing list