[llvm] r211705 - Random Number Generator (llvm)

[Per Larsen]

On Mon, Jun 30, 2014 at 11:28 AM, Reid Kleckner <rnk at google.com> wrote:

> 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.
>
The patches we're initially contributing use the RNG in CodeGen. However,
some randomizing transformations (e.g., basic block permutation) would be
IR passes so making the RNG available to both kinds of passes is the most
forward looking design IMHO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140630/ced7beb3/attachment.html>