Dan Sugalski wrote:gprof does indicate that the branch target calculation is the main culprit.
> 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.
My -Oj hack writes out currently 6 opcode_t per BB:
- bb->begin (with highbit set for a branch target)
- 4 * registers_used
(end is somehow redundant, the latter 4 could be shifted into one op).
The plain jit optimizer would need:
From this info, jit optimizer could build its internal sections (parts
Timing estimations WRT *big* programs are all rather vague, we just
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.