Message:
Someone gave me a patch to make the WITH_CLEANUP opcode behave better. I
updated it to apply on trunk cleanly.
Please review this at http://codereview.appspot.com/1863048/show
Affected files:
M JIT/llvm_fbuilder.cc
M JIT/opcodes/block.cc
M Lib/compiler/pycodegen.py
M Python/compile.c
M Python/eval.cc
M Python/import.c
Awesome! Are there any other of these variable stack adjustment
opcodes, or is this all?
We could alter the way we generate IR to use only GEPs from the base
stack pointer if this is the case, but it would be a lot of work and
would disrupt the similarity between the JIT's opcode dispatch and the
eval loop's. Hopefully LLVM will just fold away the redundant stack
pointer GEPs now that there are no phi nodes in the way.
We should also check if this produces a speedup or slowdown, but I
wouldn't expect it to have much impact.
http://codereview.appspot.com/1863048/diff/2001/3003
File Python/eval.cc (right):
http://codereview.appspot.com/1863048/diff/2001/3003#newcode3125
Python/eval.cc:3125: else
The Python style is:
...
}
else {
...
Not that it really matters. :)
> Awesome! Are there any other of these variable stack adjustment
> opcodes, or is this all?
This is it, luckily.
> We could alter the way we generate IR to use only GEPs from the base
> stack pointer if this is the case, but it would be a lot of work and
> would disrupt the similarity between the JIT's opcode dispatch and the
> eval loop's.
I want to make it like the local optimization. I'd like to reuse that
informations for unboxing, so it needs to be present very early.
> We should also check if this produces a speedup or slowdown, but I
> wouldn't expect it to have much impact.
Should not matter. After converting fbuilder to the register-based
method, we should see a speed gain. The overall effect will be good.
Regards,
J�rg Blank
Yes, switching from a stack machine to an infinite register machine
should be really good, probably both for the eval loop and for the JIT
compiler. That should be fun. :)
Reid