Author pitrou
Recipients collinwinter, jyasskin, pitrou, rhettinger
Date 2009-01-14.11:25:37
SpamBayes Score 0.00350411
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 :)
History
Date User Action Args
2009-01-14 11:25:40pitrousetrecipients: + pitrou, collinwinter, rhettinger, jyasskin
2009-01-14 11:25:39pitroulinkissue4715 messages
2009-01-14 11:25:37pitroucreate