[llvm] r211705 - Random Number Generator (llvm)

[Reid Kleckner]

On Mon, Jun 30, 2014 at 10:14 AM, Chris Lattner <clattner at apple.com> wrote:

> On Jun 30, 2014, at 9:37 AM, Stephen Crane <sjcrane at uci.edu> wrote:
> > We need to salt the RNG with Module-specific info, so that each
> > translation unit of a parallel make using the same seed actually gets
> > a different random stream. I agree that at least the seed should in
> > fact be serialized, since it is needed to construct a reproducible
> > stream. However, as long as the ModuleID is serialized (it is, right?)
> > the salt and state need not be, since the RNG state only depends on
> > the seed and the ModuleID.
> >
> > However, with all that in mind, perhaps we can move this somewhere
> > else. It was intended as a module-specific random stream, but there
> > may be another way to do this. Hopefully the final result won't
> > include too much threading/locking…
>
> If this has something to do with threading/locking, it should be in
> LLVMContext, not Module.
>
> That said, what is the expected use case for this?  The optimizer and
> backend avoid randomness whenever possible because we want reproducible
> builds.  This seems like something that should not be part of IR at all.
>  If some higher level clients want access to random numbers, they should
> manage it, it shouldn’t be magically associated with some IR concept.
>

The use case is binary diversity, so it is doing exactly what we normally
avoid.  :)

If we want both this and reproducible builds, the seed and algorithm should
*definitely* go on the module, and they should roundtrip through bitcode
and IL assembly.  There's some named metadata in there that we've decided
not to strip that we could use for this.

Apologies if this has already been asked, but can we rely on the STL RNGs
to produce identical results across implementations?  Ideally, the same
bitcode and same seed should produce the same results regardless of host
platform.

Will the RNG only be used in CodeGen or will it be used in IR passes?  If
it's in IR passes, then you need to save more intermediate state if you
want to be able to split up IR passes and still have the same results.
 OTOH, it might be OK to give up on that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140630/d911a610/attachment.html>