blob: 368875c8b97afe0466f5a49d465674199e1ba9b3 [file] [log] [blame]
njnec0c27a2005-12-10 23:11:28 +00001// This artificial program allocates and deallocates a lot of large objects
2// on the stack. It is a stress test for Memcheck's set_address_range_perms
3// (sarp) function. Pretty much all Valgrind versions up to 3.1.X do very
4// badly on it, ie. a slowdown of at least 100x.
5//
6// It is representative of tsim_arch, the simulator for the University of
7// Texas's TRIPS processor, whose performance under Valgrind is dominated by
8// the handling of one frequently-called function that allocates 8348 bytes
9// on the stack.
10
11#include <assert.h>
12#include <time.h>
13
14#define REPS 1000*1000
15
16int f(int i)
17{
18 // This nonsense is just to ensure that the compiler does not optimise
19 // away the stack allocation.
20 char big_array[8348];
21 big_array[0] = 12;
22 big_array[2333] = 34;
23 big_array[5678] = 56;
24 big_array[8347] = 78;
25 assert( 8000 == (&big_array[8100] - &big_array[100]) );
26 return big_array[i];
27}
28
29int main(void)
30{
31 int i, sum = 0;
32
33 struct timespec req;
34 req.tv_sec = 0;
35 req.tv_nsec = 100*1000*1000; // 0.1s
36
37 // Pause for a bit so that the native run-time is not 0.00, which leads
38 // to ridiculous slow-down figures.
39 nanosleep(&req, NULL);
40
41 for (i = 0; i < REPS; i++) {
42 sum += f(i & 0xff);
43 }
njnc870d182005-12-13 16:38:55 +000044 return ( sum == 0xdeadbeef ? 1 : 0 );
njnec0c27a2005-12-10 23:11:28 +000045}
46