[llvm] r211705 - Random Number Generator (llvm)

[Stephen Crane]

Yeah, that makes sense. I hadn't considered making sure that passes
always received the same stream each time, regardless of additional
passes. I think that is a quite reasonable property, especially from a
debugging standpoint.

I figure we can create an RNG with the following interface then:
RandomNumberGenerator *CreateRNG(const Module &M, StringRef PassName);

Client passes can then simply provide the current Module and the name
of the pass (which we use as a salt) to get a new generator. Am I
interpreting this correctly?

Thanks,
- stephen

On Wed, Jul 2, 2014 at 1:27 PM, Nick Lewycky <nlewycky at google.com> wrote:
> On 2 July 2014 11:52, Chandler Carruth <chandlerc at google.com> wrote:
>>
>>
>> On Tue, Jul 1, 2014 at 9:50 PM, Chris Lattner <clattner at apple.com> wrote:
>>>
>>> Any thoughts guys?  If we are unclear what the right design here is, I'd
>>> prefer you to revert the patch until it is figured out.
>>
>>
>> I'm moderately confident this isn't the right design...
>>
>> Specifically, I totally get why the seed and salt data needed by an RNG
>> might be in the module (preferably opaquely in module-level metadata or
>> something), but I don't really understand why the RN*G* would be in the
>> module rather than in the pass or thing which is generating the random data
>> for some purpose.
>
>
> Chandler and I just had a talk about this and formed some amount of
> consensus that I want to relay to the list.
>
> The RNG should have a seed in the module that we can use to create the RNG
> as needed. For predictability we agreed on MT19937 which has a lot of good
> properties (well-balanced, doesn't have a warmup period, etc). Module-level
> metadata works well for storing the seed.
>
> We need to ensure that we can reproduce runs of passes -- imagine that opt
> passes used random numbers. We need to ensure that SimplifyCFG makes the
> same decisions in "opt -instcombine -simplifycfg" and "opt -simplifycfg".
> Consequently, each pass needs to create its own RNG from the seed provided
> in the module.
>
> But we also want to avoid correlated random numbers. Each pass that creates
> an RNG should use a seed = strong-hash-function(in-module seed + per-pass
> salt). The in-module salt should probably also be generated in a manner that
> includes the initial file name. That will allow us to get different random
> numbers in a per-function pass that is processing the same function, for
> instance when included from the same header.
>
> Any consumer of these who needs properties like uniform distribution will
> need to wash the output of the RNG themselves.
>
> Stephen and Chris, does this work for both of you? Are the motivations
> behind this design clear?
>
> Nick
>