At 8:54 AM +0100 2/28/03, Leopold Toetsch wrote:
I see that limitation. But currently we have a high overhead JIT. The problem is not so much program run time, but load time.
Damn. Okay, what sort of metadata would be appropriate to aid in this? If it means having the assembler, IMCC, or some external utility write a chunk that identifies the basic blocks and edges, then I'm all for it.
gprof does indicate that the branch target calculation is the main culprit. My -Oj hack writes out currently 6 opcode_t per BB: - bb->begin (with highbit set for a branch target) - bb->end - 4 * registers_used
(end is somehow redundant, the latter 4 could be shifted into one op).
The plain jit optimizer would need: - bb->begin (implying bb->end) - (bb->end) - bb->end->branch_target (where the ->end branches to) - flags (branch source or target per block boundary), could also be coded into offsets
From this info, jit optimizer could build its internal sections (parts of blocks that are JITed or not). A BB is at least one section, but could be split into more. The register usage scan and allocation is all the same (two linear scans over all ops) and another run for actual code generation.
Here could also be some need for improvement, e.g. register usage could as well be passed by imcc (top N first usage per block - albeit this is different to current usage calculation per section). Sean already did propose this variant. This could save one scan through all ops.
Timing estimations WRT *big* programs are all rather vague, we just don't have them yet. We badly need a at least medium implemented HL *with* some RL test cases for this. The Java spec suite implemented in a supported HL would be nice to compare :) Ook.
leo
