<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div>




<div><br>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.</div>




<div><br></div><div>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.</div>




<div><br></div><div>Any consumer of these who needs properties like uniform distribution will need to wash the output of the RNG themselves.</div></div></div></div></blockquote><div><br></div><div>This plan sounds good to me overall, IIUC it often (but not always) a user to get the same randomization with the same seed even when LLVM sources differ. It also keeps the desirable properties of the current approach.</div>
<div><br></div><div>I especially like the per-pass salt idea. How would it be specified? A 64-bit integer argument to INITIALIZE_PASS should work? I'd be wary of recycling the current INITIALIZE_PASS arguments like pass name or description.</div>
<div><br></div><div>What do you mean by "The in-module salt should probably also be generated in a manner that includes the initial file name."? IIUC what you mean then this is already the case in the current patch, where the Module's ID is use (only the base name).</div>
<div><br></div><div>Agreed on getting rid of distribution.</div><div><br></div><div>One design point that Geremy Condra had suggested early on was to allow him to supply his own RNG. He was specifically looking at using a standalone file with random numbers as a stream. I think this change doesn't make it impossible, even if each pass would reuse the same file from its beginning, because of the presence of the double salt (per-Module, and per-Pass). I'll ask him to chime in.</div>
</div></div></div>