we have these nifty pccounters which will say how many times every different opcode is hit in a run of the program. I'd like to find out how many times various individual cases are hit in the assembler, both during assembly, and during the running of the assembled code. e.g. not only how often do we generate add S0, base, 0xf00 ldr rt, s0, index but how frequently are these executed?
Bug 676515 does some generalization for aspects of JM execution (number of stub calls made, approximate number of bytes of inline code and PIC stub code executed), including allowing counters to accumulate without affecting register allocation. This is already on the JM branch.
Created attachment 552635 [details] [diff] [review] rough test-- most tests fail assertions so it turns out instrumenting code causes it to blow up... a lot. When this happens inside of a PIC, we will occasionally cause a pool to need to be flushed, when before we didn't. Since we disallow pools inside of PIC's, this causes some issues. That being said, it demonstrates most of the interesting features of the counters/probes/instrumentation that I'm planning on adding.
Created attachment 554499 [details] [diff] [review] test that is much sketchier, but less likely to crash The patch is in a state where I seem to be able to add a probe (almost) anywhere, and get results. Here are execution counts for pieces of code that I think can be optimized (at least in some cases) If anyone is interested, you can see where i've inserted to probes in order to see what these counts mean. #sunspider .dtn: 911915 .dtn.huge: 911915 .store64WithAddressOffsetPatch-ii: 1780 .store64WithAddressOffsetPatch-ir: 520 .dumb_sub: 65587 .double: 3869383 .double.small: 3869383 .base32: 17567154 .base32.zero: 5147785 .base32.small: 12419369 .load64WithAddressOffsetPatch: 1262982 .null_move: 17998090 .dt32: 147817513 .dt32.small: 143137703 .dt32.zero: 4679810 .set32: 271127 .set32.ra: 52 .set32.ra.ot: 52 .set32.rr: 35321 .set32.rr.ot: 35321 .set32.ri: 235754 .set32.ri.ot: 235754 #v8: .dtn: 2914470 .dtn.huge: 2914470 .dumb_sub: 69788 .base32: 1066592 .base32.zero: 341022 .base32.small: 725570 .double: 5641920 .double.small: 5641920 .load64WithAddressOffsetPatch: 19981815 .store64WithAddressOffsetPatch-ir: 33721 .store64WithAddressOffsetPatch-ii: 333423 .null_move: 80543537 .dt32: 434065434 .dt32.medium: 7622268 .dt32.small: 393959618 .dt32.zero: 32483548 .set32: 4806421 .set32.rr: 300486 .set32.rr.ne: 127650 .set32.rr.ot: 172836 .set32.ri: 4505935 .set32.ri.ne: 1456143 .set32.ri.ot: 3049792 #kraken: .dtn: 688316 .dtn.huge: 688316 .dumb_sub: 71127 .double: 761152 .double.small: 761152 .base32: 56086471 .base32.zero: 18333190 .base32.small: 37753281 .store64WithAddressOffsetPatch-ii: 1999 .load64WithAddressOffsetPatch: 1507473 .store64WithAddressOffsetPatch-ir: 1216 .null_move: 38000560 .dt32: 273516389 .dt32.small: 271443033 .dt32.zero: 2073356 .set32: 1842942 .set32.rr: 17824 .set32.rr.ot: 17824 .set32.rr.ne: 0 .set32.ri: 1825118 .set32.ri.ot: 1825118
You need to log in before you can comment on or make changes to this bug.