Lines Matching full:basic
118 basic blocks (BBs, straight-line sequences of code) into
162 basic blocks for C++ compiled with optimisation on. Generating
257 Valgrind to run just some number of basic blocks, and then run
260 which quickly leads you to the specific basic block which is
281 tend to slightly perturb the basic block count, with the result
282 that you can get close to the basic block causing a problem but
341 every 1000 basic blocks, which means 500 to 2000 times/second
378 <para>The JITter parses x86 basic blocks into sequences
570 <para>Valgrind translates client (original) basic blocks into
571 instrumented basic blocks, which live in the translation cache
768 instructions within the same basic block. These are always
769 flushed back into memory at the end of every basic block, so that
770 the in-memory state is up-to-date between basic blocks. (This
851 basic premise is that dealing with the x86 instruction set head-on
862 <para>Parsing of an x86 basic block into a sequence of UCode
918 x86 instruction to be treated as a single basic block. The
923 <computeroutput>N</computeroutput> basic blocks. It also re-JITs
924 the final basic block executed and prints the debugging info
926 a basic block looks as it passes through the six stages mentioned
1256 end a basic block. It causes a jump to a literal (original)
1552 (this is a complete basic block, as Valgrind sees it):</para>
1727 of every basic block, from which is is inferrable that any
1731 end of every basic block. The further implication is that
1733 basic blocks, and not at arbitrary points inside basic
1735 deliver signals to the client in between basic blocks. None
1752 rather unexciting, and shown below. On longer basic blocks they
2194 it has one. In particular we can't finish the current basic
2220 client takes a fault we know at least which basic block this
2238 <para>Every 1000 basic blocks, we see if more signals have
