<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 11:24 AM, Chris Matthews <span dir="ltr"><<a href="mailto:chris.matthews@apple.com" target="_blank">chris.matthews@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree this is a great idea.  I think it needs to be fleshed out a little though.<br>
<br>
It would still be wise to run the regression detection algorithm, because the test suite changes and the machines change, and the algorithm is not perfect yet.  It would be a valuable source of information though.<br></blockquote><div><br></div><div>How would running it as part of regular testing change anything? Presumably the only purpose it would serve is retrospectively going back and seeing false-positives in the aggregate. But if we are already doing offline analysis, we can run the regression detection algorithm (or any prospective ones) offline on the raw data; it doesn't take that long.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is not a small change to how LNT works, so I think some due diligence is necessary.  Is clang *really* that deterministic, especially over successive revs? </blockquote><div><br></div><div>Yes. Actually, google's build system depends on this for its caching strategy to work and so the google guys are usually on top of any issues in this respect (thanks google guys!).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I know it is supposed to be.  Does anyone have any data to show this is going to be an effective approach?  It seems like there are benchmarks in the test-suite which use __DATE__ and __TIME__ in them. I assume that will be a problem?<br></blockquote><div><br></div><div>__DATE__ and __TIME__ should be easy to solve by modifying the benchmark, or teaching clang to always return a fixed value for them (maybe we already have this? IIRC google's build system does something like this; or maybe the do it at the OS level).</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> On May 21, 2015, at 1:43 AM, Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br>
><br>
> On 20 May 2015 at 23:31, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
>> In the last 10,000 revisions of LLVM+Clang, only 10 revisions actually<br>
>> caused the binary of MultiSource/Benchmarks/BitBench/five11 to change. So if<br>
>> just store a hash of the binary in the database, we should be able to pool<br>
>> all samples we have collected while the binary is the the same as it<br>
>> currently is, which will let us use significantly more datapoints for the<br>
>> reference.<br>
><br>
> +1<br>
><br>
><br>
>> Also, we can trivially eliminate running the regression detection algorithm<br>
>> if the binary hasn't changed.<br>
><br>
> +2!<br>
><br>
> --renato<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br>
</div></div></blockquote></div><br></div></div>