[llvm] r211705 - Random Number Generator (llvm)

[Stephen Crane]

Yes, LLVMContext was what we originally considered, but then Module
was settled on. I'm up for putting it back in Context. I think we
would then need to be careful to (re-)salt and seed the RNG
deterministically then, based on the OwnedModules, though.

We're looking to try to land the option to add diversity to
implementation details. See http://reviews.llvm.org/D1802 for more
details. A reproducible RNG is the first step needed for this.

- stephen

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.
>
> -Chris
>