Make WITH_CLEANUP have a determinstic effect on stack level. (issue1863048)

7 views
Skip to first unread message

e...@4geeks.de

unread,
Jul 29, 2010, 2:58:39 PM7/29/10
to e...@4geeks.de, unladen...@googlegroups.com, re...@codereview.appspotmail.com
Reviewers: ,

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


reid.k...@gmail.com

unread,
Jul 29, 2010, 4:08:07 PM7/29/10
to e...@4geeks.de, unladen...@googlegroups.com, re...@codereview.appspotmail.com
LGTM

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. :)

http://codereview.appspot.com/1863048/show

reid.k...@gmail.com

unread,
Jul 29, 2010, 4:07:57 PM7/29/10
to e...@4geeks.de, unladen...@googlegroups.com, re...@codereview.appspotmail.com

Jörg Blank

unread,
Jul 29, 2010, 4:25:14 PM7/29/10
to reid.k...@gmail.com, unladen...@googlegroups.com
Hi,

> 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

Reid Kleckner

unread,
Jul 29, 2010, 4:29:11 PM7/29/10
to Jörg Blank, reid.k...@gmail.com, unladen...@googlegroups.com
On Thu, Jul 29, 2010 at 1:25 PM, Jörg Blank <e...@4geeks.de> wrote:
>> 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.

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

Reply all
Reply to author
Forward
0 new messages