[PATCH] Prevent repetitive warnings for unrecognized processors and features (2nd attempt)

Renato Golin renato.golin at linaro.org
Tue Feb 4 12:31:15 PST 2014


On 4 February 2014 18:46, Jim Grosbach <grosbach at apple.com> wrote:

> It's coming from varying instantiations of things that all happen to go
> through the code path that has this terrible direct-to-errs() stuff. Those
> could honestly be changed to assertions and be more correct, imo.
>

I concur. The back end hard failing on bogus input should help *develop*
front-ends, not *hide* front-end bugs.


As a backend guy, my immediate thought is that there should be an LLVM API
> to ask "for this target, is this a valid arch/cpu name?" That gets into a
> bit of a nasty circular problem, though, as when we're parsing and
> validating the command line arguments, we don't have an LLVM backend to ask
> that question of, so we can't do that. The current implementation is to
> just duplicate the information in the front end and the backend. One could
> envision a helper library to abstract that out, but it's a fair question
> whether that'd be worth the hassle/complexity. I suspect it would, but the
> front-end folks will have a more educated opinion on that topic.
>

There was (again) the discussion on what to do about the driver regarding
target support, and that's a fourth option I hadn't thought about. We
should definitely move this issue to the Clang's list.

--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140204/fd3df75a/attachment.html>


More information about the llvm-commits mailing list