[llvm] r211705 - Random Number Generator (llvm)

Reid Kleckner rnk at google.com
Mon Jun 30 12:47:35 PDT 2014


On Mon, Jun 30, 2014 at 12:35 PM, JF Bastien <jfb at google.com> wrote:
>
> Can you elaborate? We could definitely add salt+seed to bitcode+IL if
> it's deemed better than what's currently there (they're reconstructed
> from command-line salt and Module ID).
>

http://llvm.org/docs/LangRef.html#module-flags-metadata

I used it for autolinking.  #pragma comment(lib, ...) produces something
like:
!llvm.module.flags = !{!0}
!0 = metadata !{i32 6, metadata !"Linker Options", metadata !1}
!1 = metadata !{metadata !2}
!2 = metadata !{metadata !"/DEFAULTLIB:asdf.lib"}

It could extend to your use case.


> The current design requires the exact same source version of LLVM,
> with the same target and pass ordering, for the produced binary to be
> bit-for-bit the same. Even slight changes in these could add one RNG
> query which means that all subsequent decisions will potentially be
> different.


That seems like a reasonable restriction.  I wouldn't expect differing
source revs of LLVM to produce the same results.

>> 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.
>
> It currently hard-codes std::mt19937_64, which is spec'd to return the
> same value stream:
>   typedef mersenne_twister_engine<uint_fast64_t, [some constants]>
> mt19937_64;
>   Required behavior: The 10000 th consecutive invocation of a
> default-constructed object of type mt19937_64 shall produce the value
> 9981545732273789042.
>
> Hmm, unless I'm mistaken std::uniform_int_distribution<uint64_t>
> doesn't offer such a guarantee, so this is currently broken, and the
> intended behavior isn't respected. Julian, can you look into this?
>

Cool!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140630/d6465974/attachment.html>


More information about the llvm-commits mailing list