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

[Jim Grosbach]

On Feb 3, 2014, at 2:57 PM, David Blaikie <dblaikie at gmail.com> wrote:

> 
> 
> 
> On Mon, Feb 3, 2014 at 8:29 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> Hello,
> 
> Attached is the new patch, that includes an extensive refactoring of
> MCSubtargetInfo and SubtargetFeatures, to prevent the repeated lookups of
> CPU entries.
> For the feature lookup failures, this still uses a set of strings to mark
> the features whose lookup failed; but this set now belongs to the
> MCSubtargetInfo instance.
> 
> OK to commit in this new form?
> 
> 
> Later on, this will probably be accompanied with a front-end fix, as
> suggested by Jim.
> 
> Any reason not to just fix this in the frontend to begin with? (is it going to be substantially harder)
> 
> That's a fair bit of code in LLVM. Also I'm assuming some of that code moved around and some of it is new - I don't know which bits is which, if this is the right way forward it might be helpful to have the refactoring separated from the semantic changes for greater visibility into the changes.
>  

+1. Fixing this in the front end is the right thing to do.

> 
> 
> -----Original Message-----
> From: Jim Grosbach [mailto:grosbach at apple.com]
> Sent: 30 January 2014 18:33
> To: Artyom Skrobov
> Cc: David Blaikie; llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm] r199886 - Prevent repetitive warnings for unrecognized
> processors and features
> 
> 
> On Jan 30, 2014, at 10:07 AM, Artyom Skrobov <Artyom.Skrobov at arm.com> wrote:
> 
> >> 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.
> >
> > Yes, that's how it's supposed to be; but occasionally, these diagnostics
> > "leak out" of the backend: one particular case that we're aware of, is
> >
> > $ clang -target arm -mcpu=cortex-r4 -c test.c
> > clang-3.5: warning: unknown platform, assuming -mfloat-abi=soft
> > clang-3.5: warning: unknown platform, assuming -mfloat-abi=soft
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> > 'cortex-r4' is not a recognized processor for this target (ignoring
> > processor)
> 
> Ew. That should be fixed in the front end to validate the argument to the
> -mcpu option. I agree that's pretty bad as-is.
> 

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