<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 1, 2017 at 11:34 AM Grang, Mandeep Singh <<a href="mailto:mgrang@codeaurora.org">mgrang@codeaurora.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks David and Diana for your suggestions. Yes, I am looking at<br>
setting up the builder to run after every 10 commits (is 10 a reasonable<br>
number?) and notify the blame list in case of failures.<br></blockquote><div><br>Mostly you probably just end up having the bot run as fast as possible - I think the default configuration maybe has a time based delay so it doesn't fire off on the first commit after a quiet period, but if nothing else comes in for a few minutes, it goes off and runs on a single commit rather than sitting idle.<br><br>I guess you'd find more in the zorg repository.<br><br>But please keep an eye on how reliable/actionable the emails are - if developers aren't responding to/fixing issues, or if the bot is sending fail mail for other uninteresting things (like build failures that other buildbots alerady diagnosed) - please tweak/tune or disable the buildbot. I know there's already a lot of buildbot email spam, but everything we can do to reduce the noise is really important.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
My plan is to enable this once all the current failures in the reverse<br>
builder are fixed (currently there are 4 failures).<br>
<br>
As for the bit-by-bit comparison of forward vs reverse builders is<br>
concerned I am trying to convince my team to dedicate some resources to<br>
this. Not sure how soon I can get this done :)<br>
<br>
Also thanks Diana for your ideas on how to debug/fix reverse iteration<br>
failures. Actually I have been following a similar strategy to fix these<br>
issues so far. Maybe I will update the community on this in a future<br>
email thread.<br>
<br>
--Mandeep<br>
<br>
<br>
On 8/31/2017 3:20 AM, Diana Picus wrote:<br>
> On 30 August 2017 at 18:51, David Blaikie via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Tue, Aug 29, 2017 at 11:45 AM Grang, Mandeep Singh via cfe-dev<br>
>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>> Hi All,<br>
>>><br>
>>> I wanted to share a couple of updates on the effort to uncover<br>
>>> non-determinism in LLVM through reverse iteration.<br>
>>><br>
>>> 1. Reverse iteration has now been enabled for DenseMap<br>
>>> (<a href="https://reviews.llvm.org/D35043" rel="noreferrer" target="_blank">https://reviews.llvm.org/D35043</a>)<br>
>>><br>
>>> 2. We have setup a nightly reverse iteration buildbot<br>
>>> (<a href="http://lab.llvm.org:8011/builders/reverse-iteration" rel="noreferrer" target="_blank">http://lab.llvm.org:8011/builders/reverse-iteration</a>).<br>
>>> This builds all LLVM targets with reverse iteration ON and runs ninja<br>
>>> check-all. Currently there are 14 unit test failures. Please feel free<br>
>>> to fix these.<br>
>>><br>
>>> Also currently, only I receive the nightly email notification for this<br>
>>> buildbot run. My plan is to enable sending the nightly notifications to<br>
>>> llvm-commits once all 14 failures have been resolved.<br>
>>> Please let me know if the community wants the nightly notifications even<br>
>>> with the failures.<br>
>>> As a potential next step, I was thinking about bootstrapping this<br>
>>> reverse iteration LLVM to compile itself. Not sure if it can uncover<br>
>>> more bugs but maybe worth a shot.<br>
>><br>
>> To uncover bugs in this configuration, I believe you'd want/need a<br>
>> stage2/stage3 comparison which might be a bit tricky/expensive*, something<br>
>> like:<br>
>><br>
>> build clang twice (reverse and forward enabled) then build (in one mode,<br>
>> doesn't matter which I think) clang or other release binaries (or even the<br>
>> whole release) from each of those and compare them bit-for-bit, they should<br>
>> be identical.<br>
>><br>
>> * If you want other developers to act on bugs found, the buildbot needs to<br>
>> have a short blame list (this can be done on a slow buildbot by having<br>
>> multiple slaves/builders running in parallel) but preferably also a short<br>
>> cycle time (so failures are reported soon after they're created) - otherwise<br>
>> expect to do a lot of triage yourself (& possibly leave the emails only<br>
>> going to you - because they'll have too large blame lists/revision ranges<br>
>> and people won't find them actionable) & then probably following up on the<br>
>> specific commit you believe introduced the problem and either fixing it<br>
>> yourself or replying on the commits list to report it to the original<br>
>> contributor.<br>
>><br>
> I agree with what David said here, but I just wanted to say that you<br>
> shouldn't feel too discouraged because of it.<br>
><br>
> As someone that occasionally has to bisect 5h+ worth of revisions, I<br>
> can tell you that in time you'll often be able to just look at the<br>
> revisions and spot the culprit, or maybe 2-3 candidates that have<br>
> likely caused the issue. Given that this bot does something very<br>
> specific, you can then probably just inspect the code and see what<br>
> caused the problem (if the revision doesn't touch any containers, then<br>
> it probably didn't cause the issue, right?). It's a lot easier when<br>
> you have a revision range, so it obviously won't take as long to<br>
> identify and fix as the initial failures that you are seeing now.<br>
><br>
> Ultimately, it's up to you to decide how much effort you are willing /<br>
> able to put into this. This kind of failures probably won't even occur<br>
> that often in practice, but when they do I think it's important to<br>
> find them and fix them. The best way to know for sure is to give it a<br>
> try for a while and see how it goes. If you find that it's<br>
> impractical, you can always revert to the current configuration.<br>
><br>
>>><br>
>>> All comments/suggestions welcome.<br>
>>><br>
>>> Thanks,<br>
>>> Mandeep<br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
<br>
</blockquote></div></div>