[llvm] r211705 - Random Number Generator (llvm)

[Nick Lewycky]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140702/10d46fe0/attachment.html>