Message79850
| Author |
pitrou |
| Recipients |
collinwinter, jyasskin, pitrou, rhettinger |
| Date |
2009年01月14日.11:25:37 |
| SpamBayes Score |
0.0035041145 |
| Marked as misclassified |
No |
| Message-id |
<1231932356.6605.9.camel@localhost> |
| In-reply-to |
<1231901318.17.0.42716995759.issue4715@psf.upfronthosting.co.za> |
| Content |
Le mercredi 14 janvier 2009 à 02:48 +0000, Jeffrey Yasskin a écrit :
> Looking through the patch...
>
> I don't really like the names for JUMP_OR_POP and POP_OR_JUMP.
I don't like them either, they're the only relatively short ones I could
come up with. I'll change them to your proposal
(JUMP_IF_{TRUE,FALSE}_OR_POP).
> I wonder if BINARY_AND and BINARY_OR should get predictions ... not for
> this patch.
With the patch, I don't think they need predictions anymore.
> POP_JUMP_IF_TRUE is only used in one place: assertions. I wonder if
> anyone would cry if we compiled assertions to UNARY_NOT;
> POP_JUMP_IF_FALSE instead...
No, POP_JUMP_IF_TRUE is also used when optimizing the sequence
"UNARY_NOT; POP_JUMP_IF_FALSE" (think "if not x: ...").
> In compiler_comprehension_generator, "compiler_use_next_block(c, skip);"
> is now always followed by "compiler_use_next_block(c, if_cleanup);".
> Should you remove the use(skip) call?
I'll look at this.
> In peephole.c, s/JUMP_SIGN/JUMPS_ON_TRUE/ ?
Great, another stupid name disappears :) |
|