[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
Daniel Berlin via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 6 10:20:54 PDT 2017
On Thu, Jul 6, 2017 at 8:02 AM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > -----Original Message-----
> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> > Grang, Mandeep Singh via llvm-dev
> > Sent: Thursday, July 06, 2017 2:56 AM
> > To: llvm-dev at lists.llvm.org
> > Subject: [llvm-dev] Uncovering non-determinism in LLVM - The Next Steps
> > Hi all,
> > Last year I had shared with the community my findings about instances of
> > non-determinism in llvm codegen. The major source of which was the
> > iteration of unordered containers resulting in non-deterministic
> > iteration order. In order to uncover such instances we had introduced
> > "reverse iteration" of unordered containers (currently only enabled for
> > SmallPtrSet).
> > I would now like to take this effort forward and propose to do the
> > following:
> > 1. We are in the process of setting up an internal nightly buildbot
> > which would build llvm with the cmake flag -
> > DLLVM_REVERSE_ITERATION:BOOL=ON.
> > This will make all supported containers iterate in reverse order by
> I hope you mean all supported *unordered* containers here. :-)
> > default. We would then run "ninja check-all". Any failing unit test is a
> > sign of a potential non-determinism.
> When you did this with SmallPtrSet, were there tests that failed but
> did not actually indicate non-determinism?
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
This is "non-deterministic" in the sense that the textual form is
different, but has the same semantic meaning either way.
(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)
Whether you consider this non-deterministic depends on your goal.
I would argue that any pass that behaves differently given
phi [[1, block 1], [2, block 2]]
phi [[2, block 2], [1, block 1]]
is just flat out broken (and we have some that break due to poor design,
So i wouldn't consider the above to be non-deterministic in any meaningful
sense, despite it outputting different textual form.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev