This is an archive of the discontinued LLVM Phabricator instance.

[llvm-stress] Use C++11 mersenne_twister_engine random device instead of our own (PR32585)
AbandonedPublic

Authored by RKSimon on Jun 13 2017, 11:53 AM.

Details

Summary

As discussed on D34089, this patch replaces the existing custom Random class with the C++ mersenne_twister_engine instead, which should maintain equivalent values on different targets.

llvm-stress is still driven by an input seed, but the change in randomizer will mean that the fuzz test codegen won't match previous results.

Diff Detail

Repository
rL LLVM

Event Timeline

RKSimon created this revision.Jun 13 2017, 11:53 AM
chandlerc requested changes to this revision.Jun 13 2017, 12:03 PM

Rather than using the RNG engine directly and using mod operations, the correct usage pattern is to use a distribution over the desired range and let it pull raw entropy out of the engine while mapping it into whatever distribution the use case requires.

See http://en.cppreference.com/w/cpp/numeric/random/uniform_int_distribution for more details.

This revision now requires changes to proceed.Jun 13 2017, 12:03 PM
RKSimon updated this revision to Diff 102657.Jun 15 2017, 5:31 AM
RKSimon edited edge metadata.

Updated as requested by @chandlerc - my only concern is I have no idea if uniform_int_distribution guarantees the same behaviour on different targets as mersene does.

mclow.lists edited edge metadata.Jun 15 2017, 10:07 AM

my only concern is I have no idea if uniform_int_distribution guarantees the same behaviour on different targets as mersene does

It does not.
[rand.dist.general]/3:

The algorithms for producing each of the specified distributions are implementation-defined.

my only concern is I have no idea if uniform_int_distribution guarantees the same behaviour on different targets as mersene does

It does not.
[rand.dist.general]/3:

The algorithms for producing each of the specified distributions are implementation-defined.

Wait, really? This makes using a seeded PRNG inside any of the standard distributions pretty much useless -- you can seed things all you want but you can't actually reproduce the particular results when fed through a distribution...

If this is true, it seems like yet another horrible and glaring hole in the entire PRNG system of the C++ standard library, which is pretty sad IMO.

We still shouldn't (IMO) use the raw and undistributed results of the PRNG engine. But maybe we have to build our own API (perhaps based in part on libc++'s code) since we can't actually use the standard library.

my only concern is I have no idea if uniform_int_distribution guarantees the same behaviour on different targets as mersene does

It does not.
[rand.dist.general]/3:

The algorithms for producing each of the specified distributions are implementation-defined.

Wait, really? This makes using a seeded PRNG inside any of the standard distributions pretty much useless -- you can seed things all you want but you can't actually reproduce the particular results when fed through a distribution...

I wouldn't go so far as to say that makes the seeding useless, there are still plenty of use cases (and, FWIW, makes them no better than the system *rand*() functions). It does rule out this use case, however.

jroelofs added inline comments.
tools/llvm-stress/llvm-stress.cpp
47

Can you use the llvm::RandomNumberGenerator wrapper instead? That prevents accidentally copying it.

RKSimon added inline comments.Jun 26 2017, 6:28 AM
tools/llvm-stress/llvm-stress.cpp
47

Maybe, although it'll need a slight refactor of how the salt/seeding system works. llvm::RandomNumberGenerator creates a salt based on the pass' name and module id. We need the ability to support llvm-stress providing a seed value at the command line

chandlerc resigned from this revision.Dec 4 2018, 12:56 AM
RKSimon abandoned this revision.Jun 22 2020, 12:12 PM

Abandoning ancient patch