|
From: mohit t. <tew...@ya...> - 2007-10-25 21:21:58
|
Hello,=0A=0AI wished to see the break up of 32b and non-32b stores in bench= mark programs. I assumed that the mc_STOREV* functions in VG-3.2.3/Memcheck= /mc_main.c serviced appropriate sized stores in the emulated instruction se= t, and inserted counters for the total number of stores (in mc_translate.c,= before do_shadow_Store), and for the number of 8b,16b,32b and 64b stores (= in mc_main.c, inside mc_STOREV*). =0A=0ASurprisingly, even though I'm using= a 32bit machine, I found that the mc_STOREV64 counter had pretty substanti= al values. In fact, for 171.swim, 32M of a total 39M stores were 64b. I als= o thought that the number of sub-word stores was pretty high (for eg. bzip2= had 101M of 283M of its stores as 8b/16b). Both swim and bzip2 used the lg= red inputs in the minnespec suite.=0A=0AI guess my understanding of the mc_= STOREV functions is incorrect. I see that these functions get chosen based= on the IRType of the store instruction, but I do not know how the IRType g= ets set when a client program is translated.=0A=0ADo these functions have a= ny correlation with the number of respective stores a program (say swim) wo= uld have if it was run natively? Or is there any other way I can track the = same?=0A=0AThanks in advance for your help.=0A=0AMohit=0A------------------= --=0A=0A=0A=0A=0A=0A=0A__________________________________________________= =0ADo You Yahoo!?=0ATired of spam? Yahoo! Mail has the best spam protectio= n around =0Ahttp://mail.yahoo.com |
|
From: Nicholas N. <nj...@cs...> - 2007-10-25 22:26:38
|
On Thu, 25 Oct 2007, mohit tewari wrote: > I wished to see the break up of 32b and non-32b stores in benchmark > programs. I assumed that the mc_STOREV* functions in > VG-3.2.3/Memcheck/mc_main.c serviced appropriate sized stores in the > emulated instruction set, and inserted counters for the total number of > stores (in mc_translate.c, before do_shadow_Store), and for the number of > 8b,16b,32b and 64b stores (in mc_main.c, inside mc_STOREV*). That's correct, ie. mc_STOREV32 should get called once per 32-bit store, and so on with the others. > Surprisingly, even though I'm using a 32bit machine, I found that the > mc_STOREV64 counter had pretty substantial values. In fact, for 171.swim, > 32M of a total 39M stores were 64b. I also thought that the number of > sub-word stores was pretty high (for eg. bzip2 had 101M of 283M of its > stores as 8b/16b). Both swim and bzip2 used the lgred inputs in the > minnespec suite. IIRC, 171.swim is an FP program, and Valgrind uses 64-bit FP values, even on x86 (80-bit FP types are reduced to 64-bit types on x86). bzip2 does lots of byte operations, AFAIK -- I suspect most of those sub-32-bit operations are 8-bits, and there won't be many 16-bit ones. > I guess my understanding of the mc_STOREV functions is incorrect. I see > that these functions get chosen based on the IRType of the store > instruction, but I do not know how the IRType gets set when a client > program is translated. > > Do these functions have any correlation with the number of respective > stores a program (say swim) would have if it was run natively? Or is there > any other way I can track the same? They should match very closely. Nick |