#93229 introduced a regression in how aggressively we quicken some for loops. Minimal example:

def f(x: bool) -> None:
    for i in range(1_000_000):
        if x:
            pass

f(True) will quicken this code, but f(False) will not, even though both contain the same number of back edges. The issue is that we only quicken on unconditional backwards jumps, not on conditional ones.

We've known about this limitation for some time, in particular with regard to while loops. Since we check the loop condition at the bottom of while loops, one call is not enough to quicken w:

def w() -> None:
    i = 0
    while i < 1_000_000:
        i += 1

@markshannon has expressed a preference for having all branches be forward (i.e. replacing backward POP_JUMP_IF_FALSE(x) instructions with POP_JUMP_FORWARD_IF_TRUE(1); JUMP_BACKWARD(x) in the assembler). @iritkatriel believes that this shouldn't be too difficult, based on recent assembler rewrites.

CC @sweeneyde

Linked PRs

• gh-93554: add test for quickening of code in loops ending with conditional statement #119485