llvm dev - Apr 2014 - [LLVMdev] Proposal: Move host CPU auto-detection out of the TargetMachine

On Fri, Apr 11, 2014 at 3:58 PM, Jim Grosbach <grosbach at apple.com>
wrote:
>
> Now, one additional thing we could do (outside the scope of this proposal)
> is also implement a fuzzer of some kind to look for target tests that don’t
> have an explicit arch/feature/whatever setting on the RUN line and run it
> with all available -mcpu= values and see if it still passes (which is what
> the lack of such things on the RUN line implies).

We should totally do this.  We'll could have 'check' and
'check-alltargets'
targets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140411/989ea7a8/attachment.html>

On Fri, Apr 11, 2014 at 4:02 PM, Reid Kleckner <rnk at google.com>
wrote:
> On Fri, Apr 11, 2014 at 3:58 PM, Jim Grosbach <grosbach at apple.com>
wrote:
>>
>> Now, one additional thing we could do (outside the scope of this
proposal)
>> is also implement a fuzzer of some kind to look for target tests that
don't
>> have an explicit arch/feature/whatever setting on the RUN line and run
it
>> with all available -mcpu= values and see if it still passes (which is
what
>> the lack of such things on the RUN line implies).
>
>
> We should totally do this.  We'll could have 'check' and
'check-alltargets'
> targets.
I don't feel too strongly, but ultimately am not going to kick and
scream if it happens. :)

I'm vaguely against it, but with this sort of workaround in testing I
guess it's ok.

-eric

OK. Seems we have a consensus, then. We can sort any follow-up details in
post-review. Thanks, all!

r206094 and r206095 for the x86 and ‘llc’ changes, respectively.

-Jim

On Apr 11, 2014, at 4:20 PM, Eric Christopher <echristo at gmail.com>
wrote:
> On Fri, Apr 11, 2014 at 4:02 PM, Reid Kleckner <rnk at google.com>
wrote:
>> On Fri, Apr 11, 2014 at 3:58 PM, Jim Grosbach <grosbach at
apple.com> wrote:
>>> 
>>> Now, one additional thing we could do (outside the scope of this
proposal)
>>> is also implement a fuzzer of some kind to look for target tests
that don't
>>> have an explicit arch/feature/whatever setting on the RUN line and
run it
>>> with all available -mcpu= values and see if it still passes (which
is what
>>> the lack of such things on the RUN line implies).
>> 
>> 
>> We should totally do this.  We'll could have 'check' and
'check-alltargets'
>> targets.
> 
> I don't feel too strongly, but ultimately am not going to kick and
> scream if it happens. :)
> 
> I'm vaguely against it, but with this sort of workaround in testing I
> guess it's ok.
> 
> -eric