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

Jim Grosbach grosbach at apple.com
Tue Feb 4 10:46:59 PST 2014


On Feb 4, 2014, at 10:29 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 4 February 2014 18:14, Jim Grosbach <grosbach at apple.com> wrote:
> Why? I haven’t seen any reason for doing anything in the backend other than avoiding doing the work in the front end.
> 
> I may have gotten that wrong, but I thought that the warning message was coming from the back-end by trying the same thing over and over again.

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.

> 
> It's true that the front-end should only pass recognizable CPUs (as I said earlier, it should convert to the default CPU if not), but I was under the impression that this could also happen with other tools (llc, etc) that didn't use Clang's driver. Don't take my opinion on this as kosher, it certainly isn't.
> 

Yeah, if you feed a garbage value to llc, et. al., I’m sure similar things happen. That’s orthogonal to the root issue at hand here, though. The core bug is that the clang front end is relying on code deep in the MC layer for validation, and error reporting, of command line arguments. That’s crazy and should be fixed.

If llc and friends have unfriendly error reporting for things like this, that sucks, but I’m not nearly as concerned, as those are purely development tools and not meant for production. It’d be nice to clean them up, but this would only be the tip of that iceberg. You can pass all sorts of crazy things to those tools and get “interesting” results.

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.

-Jim

> 
> Sounds like something that should be discussed with folks on cfe-commits/cfe-dev.
> 
> Undoubtedly.
> 
> cheers,
> --renato

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


More information about the llvm-commits mailing list