summaryrefslogtreecommitdiffstats
path: root/llvm/utils/shuffle_fuzz.py
Commit message (Collapse)AuthorAgeFilesLines
* [Utils] Updated shuffle fuzz script to generate more modern (valid) IR.Simon Pilgrim2015-11-221-2/+2
| | | | llvm-svn: 253821
* [shuffles] Tweak my shufflevector fuzz test generation script to produceChandler Carruth2015-02-181-3/+2
| | | | | | more useful output. No more null bytes printed, and now with a newline. llvm-svn: 229599
* [shuffle] Teach the shufflevector fuzzer to support fixed element types.Chandler Carruth2014-08-171-6/+12
| | | | | | | I'm using this to try to find more minimal test cases by re-fuzzing within a specific domain once errors are found. llvm-svn: 215823
* [shuffle] Stand back! I'm about to (try to) do math!Chandler Carruth2014-08-131-2/+39
| | | | | | | | | | | | | | | | | | | Especially with blends and large tree heights there was a problem with the fuzzer where it would end up with enough undef shuffle elements in enough parts of the tree that in a birthday-attack kind of way we ended up regularly having large numbers of undef elements in the result. I was seeing reasonably frequent cases of *all* results being undef which prevents us from doing any correctness checking at all. While having undef lanes is important, this was too much. So I've tried to apply some math to the probabilities of having an undef lane and balance them against the tree height. Please be gentle, I'm really terrible at math. I probably made a bunch of amateur mistakes here. Fixes, etc. are quite welcome. =D At least in running it some, it seems to be producing more interesting (for correctness testing) results. llvm-svn: 215540
* [shuffle] Make the seed an optional component and add support forChandler Carruth2014-08-131-2/+3
| | | | | | letting the python very directly compute a UUID. llvm-svn: 215533
* [shuffle] Teach the shuffle fuzzer to fuzz blends, including formingChandler Carruth2014-08-131-39/+67
| | | | | | | | | | | | | | | | | a tree of inputs to blend iteratively together. This required a pretty substantial rewrite of the innards. The number of shuffle instructions is now bounded in terms of tree-height. There is a flag to disable blends so that its still possible to test single input shuffles. I've also improved various aspects of how the test program is generated, primarily to simplify the test harness and allow some optimizations to clean up how we actually check the results and build up the inputs. Again, apologies for my likely horrible use of Python... But hey, it works! (Ish?) llvm-svn: 215530
* [shuffle] Tweak the shuffle fuzzer to support bigger seeds. I'mChandler Carruth2014-08-131-6/+6
| | | | | | currently using UUIDs to seed this in order to scan a bigger range. llvm-svn: 215521
* Add an option to the shuffle fuzzer that lets you fuzz exclusivelyChandler Carruth2014-08-071-2/+16
| | | | | | | | | within a single bit-width of vectors. This is particularly useful for when you know you have bugs in a certain area and want to find simpler test cases than those produced by an open-ended fuzzing that ends up legalizing the vector in addition to shuffling it. llvm-svn: 215056
* Add a vector shuffle fuzzer.Chandler Carruth2014-08-071-0/+170
This is a python script which for a given seed generates a random sequence of random shuffles of a random vector width. It embeds this into a function and emits a main function which calls the test routine and checks that the results (where defined) match the obvious results. I'll be using this to drive out miscompiles from the new vector shuffle logic now that it is clean of any crashes I can find with llvm-stress. Note, my python skills are very poor. Sorry if this is terrible code, and feel free to tell me how I should write this or just patch it as necessary. The tests generated try to be very portable and use boring C routines. It technically will mis-declare the C routines and pass 32-bit integers to parametrs that expect 64-bit integers. If someone wants to fix this and has less terrible ideas of how to do it, I'm all ears. Fortunately, this "just works" for x86. =] llvm-svn: 215054
OpenPOWER on IntegriCloud