Diego Novillo
2014-Jan-09 16:42 UTC
[LLVMdev] New -O3 Performance tester - Use hardware to get reliable numbers
On Wed, Jan 8, 2014 at 4:07 PM, Sean Silva <chisophugis at gmail.com> wrote:> > > > On Wed, Jan 8, 2014 at 7:58 AM, Diego Novillo <dnovillo at google.com> wrote: >> >> On Tue, Jan 7, 2014 at 8:48 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >> > sean:~/pg/llvm/llvm % git log --oneline --since='1 month ago' | wc -l >> > 706 >> > sean:~/pg/llvm/llvm % git log --oneline --since='1 month ago' ./test | >> > wc -l >> > 317 >> >> Wouldn't this also catch commits to code generation that added tests as >> well? >> > > I'm not sure what you mean or how it would affect what I'm saying. Any > commit that affects code generation should include a test (there may be some > rare exceptions, but this is the general rule).If you pruned the commits that include directory ./test, won't that prune the associated codegen patch as well? This would cause coverage loss for the tester. Or maybe I just did not understand what you were proposing :) Diego.
David Tweed
2014-Jan-09 16:50 UTC
[LLVMdev] New -O3 Performance tester - Use hardware to get reliable numbers
Hi Diego,
I think what Sean was saying was to collect (filter) only commits that
_do_ touch the tests subtree. The git example is saying that, in a
time period when there were 706, there were only 317 that touched
tests and hence need checking (hence the comment about doubling).
("Filter" is annoyingly ambiguous verb in English because it can mean
either that you're keeping the things stopped by the filter, or that
you're throwing away things stopped by the filter. I could never
remember which one Haskell's filter function did and always had to
look it up.)
On Thu, Jan 9, 2014 at 4:42 PM, Diego Novillo <dnovillo at google.com>
wrote:> On Wed, Jan 8, 2014 at 4:07 PM, Sean Silva <chisophugis at gmail.com>
wrote:
>>
>>
>>
>> On Wed, Jan 8, 2014 at 7:58 AM, Diego Novillo <dnovillo at
google.com> wrote:
>>>
>>> On Tue, Jan 7, 2014 at 8:48 PM, Sean Silva <chisophugis at
gmail.com> wrote:
>>>
>>> > sean:~/pg/llvm/llvm % git log --oneline --since='1 month
ago' | wc -l
>>> > 706
>>> > sean:~/pg/llvm/llvm % git log --oneline --since='1 month
ago' ./test |
>>> > wc -l
>>> > 317
>>>
>>> Wouldn't this also catch commits to code generation that added
tests as
>>> well?
>>>
>>
>> I'm not sure what you mean or how it would affect what I'm
saying. Any
>> commit that affects code generation should include a test (there may be
some
>> rare exceptions, but this is the general rule).
>
> If you pruned the commits that include directory ./test, won't that
> prune the associated codegen patch as well? This would cause coverage
> loss for the tester.
>
> Or maybe I just did not understand what you were proposing :)
>
>
> Diego.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david.tweed at gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
Diego Novillo
2014-Jan-09 16:56 UTC
[LLVMdev] New -O3 Performance tester - Use hardware to get reliable numbers
On Thu, Jan 9, 2014 at 11:50 AM, David Tweed <david.tweed at gmail.com> wrote:> Hi Diego, > > I think what Sean was saying was to collect (filter) only commits that > _do_ touch the tests subtree.Ah, the exact opposite of what I understood. OK, yes, that makes sense (assuming every codegen patch has an associated test, which should be a pretty safe assumption). Diego.