Sean O'Rourke wrote:
On Thu, 20 Feb 2003, Leopold Toetsch wrote:What do people think?Cool idea -- a lot of optimization-helpers could eventually be passed on to the jit (possibly in the metadata?). One thought -- the information imcc computes should be platform-independent. e.g. it could pass a control flow graph to the JIT, but it probably shouldn't do register allocation for a specific number of registers. How much worse do you think it would be to have IMCC just rank the Parrot registers in order of decreasing spill cost, then have the JIT take the top N, where N is the number of available architectural registers?
The registers are already in that order (with -Op or -Oj), this wouldn't be a problem. Difficulties arise, when it comes to the register load/save instructions, which get inserted by imcc in my scheme. These are definitely processor/$arch specific. They depend on the number of mappable (and non-preserved too) registers, and on the state of the op_jit function table.
Of course CFG and register life information could be passed on to the JIT, but this seems a little bit complicated, as JIT has it's own sections, which match either a basic block from imcc or are a sequence of non-JITable instructions.
But in the long run, it could be a way to go. OTOH - PBC compatibility is not a big point here, when JIT is involved: in 99% of the time the code would run on the machine, where it is generated.
And it would be AFAIK easier, to make some JIT crosscompiler. This would basically only need the amount of mappable registers and the extcall bits from the jump table, read in from some config file.
/s
leo
