summaryrefslogtreecommitdiff
path: root/libc/test/src/stdlib/rand_test.cpp
AgeCommit message (Collapse)Author
2024-11-01[libc] Remove the #include <stdlib.h> header (#114453)Job Henandez Lara
2024-06-26[libc] Make 'rand()' thread-safe using atomics instead of TLS (#96692)Joseph Huber
Summary: Currently, we implement the `rand` function using thread-local storage. This is somewhat problematic because not every target supports TLS, and even more do not support non-zero initializers on TLS. The C standard states that the `rand()` function need not be thread, safe. However, many implementations provide thread-safety anyway. There's some confusing language in the 'rationale' section of https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html, but given that `glibc` uses a lock, I think we should make this thread safe as well. it mentions that threaded behavior is desirable and can be done in the two ways: 1. A single per-process sequence of pseudo-random numbers that is shared by all threads that call rand() 2. A different sequence of pseudo-random numbers for each thread that calls rand() The current implementation is (2.) and this patch moves it to (1.). This is beneficial for the GPU case and more generic support. The downside is that it's slightly slower to do these atomic operations, the fast path will be two atomic reads and an atomic write.
2023-10-19[libc] Partially implement 'rand' for the GPU (#66167)Joseph Huber
Summary: This patch partially implements the `rand` function on the GPU. This is partial because the GPU currently doesn't support thread local storage or static initializers. To implement this on the GPU. I use 1/8th of the local / shared memory quota to treak the shared memory as thread local storage. This is done by simply allocating enough storage for each thread in the block and indexing into this based off of the thread id. The downside to this is that it does not initialize `srand` correctly to be `1` as the standard says, it is also wasteful. In the future we should figure out a way to support TLS on the GPU so that this can be completely common and less resource intensive.
2023-09-26[libc] Mass replace enclosing namespace (#67032)Guillaume Chatelet
This is step 4 of https://discourse.llvm.org/t/rfc-customizable-namespace-to-allow-testing-the-libc-when-the-system-libc-is-also-llvms-libc/73079
2023-09-12[libc] Improve the implementation of the rand() function (#66131)Joseph Huber
Summary: This patch improves the implementation of the standard `rand()` function by implementing it in terms of the xorshift64star pRNG as described in https://en.wikipedia.org/wiki/Xorshift#xorshift*. This is a good, general purpose random number generator that is sufficient for most applications that do not require an extremely long period. This patch also correctly initializes the seed to be `1` as described by the standard. We also increase the `RAND_MAX` value to be `INT_MAX` as the standard only specifies that it can be larger than 32768.
2023-02-07[libc][NFC] Move UnitTest and IntegrationTest to the 'test' directory.Siva Chandra Reddy
This part of the effort to make all test related pieces into the `test` directory. This helps is excluding test related pieces in a straight forward manner if LLVM_INCLUDE_TESTS is OFF. Future patches will also move the MPFR wrapper and testutils into the 'test' directory.
2022-10-04[libc] implement basic rand and srandMichael Jones
This provides the reference implementation of rand and srand. In future this will likely be upgraded to something that supports full ints. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D135187