René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Conditional backward edges should help \"warm up\" code","articleBody":"#93229 introduced a regression in how aggressively we quicken some `for` loops. Minimal example:\r\n\r\n```py\r\ndef f(x: bool) -\u003e None:\r\n    for i in range(1_000_000):\r\n        if x:\r\n            pass\r\n```\r\n\r\n`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.\r\n\r\nWe'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`:\r\n\r\n```py\r\ndef w() -\u003e None:\r\n    i = 0\r\n    while i \u003c 1_000_000:\r\n        i += 1\r\n```\r\n\r\n@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.\r\n\r\nCC @sweeneyde \n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-119485\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/brandtbucher","@type":"Person","name":"brandtbucher"},"datePublished":"2022-06-06T22:49:32.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":11},"url":"https://github.com/93554/cpython/issues/93554"}