Author: Maciej Fijalkowski <[email protected]> Branch: extradoc Changeset: r3916:f35d7b65dba4 Date: 2011-09-28 10:44 -0300 http://bitbucket.org/pypy/extradoc/changeset/f35d7b65dba4/
Log: merge diff --git a/planning/jit.txt b/planning/jit.txt --- a/planning/jit.txt +++ b/planning/jit.txt @@ -15,10 +15,6 @@ - maybe refactor a bit the x86 backend, particularly the register allocation -- think about having different bytecode for "xyz %s" % stuff when left side - is a compile time constant (and call unrolled version of string formatting - loop in this case). (done on unroll-if-alt, different approach though) - - consider how much old style classes in stdlib hurt us. - the integer range analysis cannot deal with int_between, because it is @@ -90,6 +86,9 @@ - ((turn max(x, y)/min(x, y) into MAXSD, MINSD instructions when x and y are floats.)) (a mess, MAXSD/MINSD have different semantics WRT nan) +- list.pop() (with no arguments) calls into delitem, rather than recognizing that + no items need to be moved + BACKEND TASKS ------------- @@ -114,15 +113,6 @@ LATER (maybe) TASKS ------------------- -- think out looking into functions or not, based on arguments, - for example contains__Tuple should be unrolled if tuple is of constant - length. This should be possible now that we do some heap opt during - tracing. - Also, an unrolled loop means several copies of the guards, which may - fail independently, leading to an exponential number of bridges - (done on unroll-if-alt branch, more opts in frontend needed to work all - the time) - - ((merge tails of loops-and-bridges?)) UNROLLING _______________________________________________ pypy-commit mailing list [email protected] http://mail.python.org/mailman/listinfo/pypy-commit
