[llvm-dev] Uncovering non-determinism in LLVM - The Next Steps

[Daniel Berlin via llvm-dev]

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
smallptrset iteration.
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]]
and
phi [[2, block 2], [1, block 1]]

is just flat out broken (and we have some that break due to poor design,
etc)

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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/1188e387/attachment.html>