<div>Right, the only way I can think of is if there are two possible simplifications depending on operand ordering and we choose different ones.  IMHO in those cases we should just fix the inconsistencies.</div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 9, 2017, 11:43 AM Davide Italiano via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">davide added inline comments.<br>
<br>
<br>
================<br>
Comment at: llvm/trunk/lib/Transforms/Scalar/NewGVN.cpp:742<br>
+            [&](const Use *U1, const Use *U2) {<br>
+              return PN->getIncomingBlock(*U1) < PN->getIncomingBlock(*U2);<br>
+            });<br>
----------------<br>
efriedma wrote:<br>
> davide wrote:<br>
> > efriedma wrote:<br>
> > > Is there any possibility that sorting by pointer values here will give non-deterministic output?  If there isn't, please add a comment explaining why.<br>
> > I thought about this when writing the patch, and I think the answer is no (but I'm nervous when it comes to ordering based on pointers given I tracked down several non-determinism bugs because of these).<br>
> > As far as I can tell, we don't actually rely on the ordering for anything significant, e.g. we don't create new instructions based on that ordering.<br>
> > Does this make sense? If so, I'll add a comment. (and thanks for your feedback).<br>
> Yes, that makes sense.<br>
r302566. Thanks.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D32990" rel="noreferrer" target="_blank">https://reviews.llvm.org/D32990</a><br>
<br>
<br>
<br>
</blockquote></div></div>