[PATCH] D32990: [NewGVN] Take in account incoming edges computing congruent PhiExpression(s)

Daniel Berlin via llvm-commits llvm-commits at lists.llvm.org
Tue May 9 14:00:47 PDT 2017


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.


On Tue, May 9, 2017, 11:43 AM Davide Italiano via Phabricator <
reviews at reviews.llvm.org> wrote:

> davide added inline comments.
>
>
> ================
> Comment at: llvm/trunk/lib/Transforms/Scalar/NewGVN.cpp:742
> +            [&](const Use *U1, const Use *U2) {
> +              return PN->getIncomingBlock(*U1) <
> PN->getIncomingBlock(*U2);
> +            });
> ----------------
> efriedma wrote:
> > davide wrote:
> > > efriedma wrote:
> > > > 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.
> > > 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).
> > > 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.
> > > Does this make sense? If so, I'll add a comment. (and thanks for your
> feedback).
> > Yes, that makes sense.
> r302566. Thanks.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D32990
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170509/3a1ff3ff/attachment.html>


More information about the llvm-commits mailing list