<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 1:08 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Thu, Jul 6, 2017 at 12:34 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_7196935869793616893h5">On Thu, Jul 6, 2017 at 10:20 AM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-m_7196935869793616893m_5771199437449982016h5">On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
<br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists<wbr>.llvm.org</a>] On Behalf Of<br>
> Grang, Mandeep Singh via llvm-dev<br>
> Sent: Thursday, July 06, 2017 2:56 AM<br>
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: [llvm-dev] Uncovering non-determinism in LLVM - The Next Steps<br>
><br>
> Hi all,<br>
><br>
> Last year I had shared with the community my findings about instances of<br>
> non-determinism in llvm codegen. The major source of which was the<br>
> iteration of unordered containers resulting in non-deterministic<br>
> iteration order. In order to uncover such instances we had introduced<br>
> "reverse iteration" of unordered containers (currently only enabled for<br>
> SmallPtrSet).<br>
> I would now like to take this effort forward and propose to do the<br>
> following:<br>
><br>
> 1. We are in the process of setting up an internal nightly buildbot<br>
> which would build llvm with the cmake flag -<br>
> DLLVM_REVERSE_ITERATION:BOOL=O<wbr>N.<br>
> This will make all supported containers iterate in reverse order by<br>
<br>
</span>I hope you mean all supported *unordered* containers here. :-)<br>
<span><br>
> default. We would then run "ninja check-all". Any failing unit test is a<br>
> sign of a potential non-determinism.<br>
<br>
</span>When you did this with SmallPtrSet, were there tests that failed but<br>
did not actually indicate non-determinism?<br></blockquote><div><br></div></div></div><div>An example of this is the order of predecessors in the IR in phi nodes. There are passes that will create them in different orders depending on smallptrset iteration.</div><div>This is "non-deterministic" in the sense that the textual form is different, but has the same semantic meaning either way.</div><div>(Let's put aside the fact that allowing them to have a different order than the actual block predecessors is a pointless waste of time :P)</div><div><br></div><div>Whether you consider this non-deterministic depends on your goal.</div><div><br></div><div>I would argue that any pass that behaves differently given </div><div>phi [[1, block 1], [2, block 2]]</div><div>and </div><div>phi [[2, block 2], [1, block 1]] </div><div><br></div><div>is just flat out broken (and we have some that break due to poor design, etc)</div><div><br></div><div>So i wouldn't consider the above to be non-deterministic in any meaningful sense, despite it outputting different textual form.</div></div></div></div></blockquote><div><br></div></div></div><div>One of our definitions of non-determinism is simply "output from command line tools should always be bit identical given identical inputs", which is suitable for content-based caching build systems like Bazel.</div></div></div></div></blockquote></div></div><div>Just to point out: These systems already often have to ignore whitespace differences, etc. </div><div><br></div><div>I'd also argue any of these content-based caching build systems is going to be rarely used if they require every single tool that uses them to produce bit identical output (IE boiling the ocean), as opposed to letting the tools define what identical means or something.</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I don't know how our bitcode encoding compares to the textual IR in the case of your phi example, but assuming that that difference makes it into the bitcode too, it would cause e.g. ThinLTO bitcode artifacts to violate the content-based caching assumptions, even if semantically to the compiler the difference is immaterial.</div></div></div></div></blockquote><div><br></div></span><div>You are certainly welcome to try to make all these things that are semantically identical try to be completely syntactically identical as well, but i'm pretty uninterested in slowing down or banning passes from doing certain things to do that.</div><div><br></div><div>IE if you want this to happen, IMHO, this should be happening in output writing, not somewhere else.</div><div><br></div><div>To give another example: Currently, IIRC, the order of basic blocks the function iterator goes through is "as they appear in input".</div><div>There is no real defined or required ordering (IE it's not, for example, sorted in a preorder walk from the entry block or something) for correctness.</div><div><br></div><div>I could make a pass that randomizes the list which for (auto &BB : F) walks, and nothing else in the compiler should change :)</div><div><br></div><div>I don't think you can say such a pass is broken.</div><div><br></div><div>Hence I think if you want such constraints, they need to be placed on output orderings, not on what passes do.</div></div></div></div></blockquote><div><br></div><div><div>Yeah, I agree it is mostly (if not entirely) an output canonicalization issue in these cases.</div><div><br></div><div>-- Sean Silva</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> I know that Richard has mentioned in the past at least for Clang the intention is bit-identical output for bit-identical input.</div><span class="gmail-m_7196935869793616893HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div></div></div></div>
<br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>