|
From: Nicholas N. <nj...@ca...> - 2002-11-20 12:23:57
|
On 19 Nov 2002, Jeremy Fitzhardinge wrote: > Well, I found that there is an easy way of getting V to generate > extended basic blocks: simply allow conditional jumps to not end the > basic block (they code was all set up to do it, complete with > almost-accurate comment). I haven't done on overall measurement of what > the average increase in BB length is, but from looking a the output of > --trace-codegen, they can get quite long. It certainly allows us to see > what the effect of having long register lifetimes is vs. > indescriminately over-compiling things. The results are far from > conclusive: it seems to vary between a few percent better to a few > percent worse (and it also seems to depend on the skin, though I haven't > really tested that yet). Does this mean that the fall-through JMP back to the dispatcher is replaced by the following basic block? ie. you're allowing multiple exits from a basic block? ie. [code] Jcc X JMP 0xY becomes [code] Jcc ... [code for block at 0xY] ? Interesting that this doesn't make a definite improvement. ---- Another way to extend basic blocks is to inline direct calls in the same way, eg: [code] JMP-c 0xX becomes [code] [code for block at 0xX] Problem with that is that it screws up function-entry detection for skins -- currently to detect function entry they can call VG_(get_fnname_if_entry)() at the start of a basic block to determine if it's the first basic block in a function. With this optimisation they'd have to do it for every x86 instruction, urgh. ---- Similarly direct JMPs seem pretty common, perhaps they too could be inlined: [code] JMP 0xY becomes [code] [code for block at 0xY] ---- This sort of inlining seems nicer than chaining. Would it be hard? Is it any different in principle to what Jeremy's already implemented? N |