Skip to content

bpo-41323: Perform 'peephole' optimizations directly on the CFG. #21517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

markshannon
Copy link
Member

@markshannon markshannon commented Jul 17, 2020

  • Saves about 200 lines of code
  • Breaks the coupling between the optimizer and the bytecode and line number table formats.

https://bugs.python.org/issue41323

@markshannon markshannon changed the title bpo-41323: Move 'peephole' optimizations directly on the CFG. bpo-41323: Perform 'peephole' optimizations directly on the CFG. Jul 17, 2020
Python/compile.c Outdated
PyObject *names = NULL;
PyObject *varnames = NULL;
PyObject *name = NULL;
PyObject *freevars = NULL;
PyObject *cellvars = NULL;
PyObject *bytecode = NULL;
// PyObject *bytecode = NULL;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you forget this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks.

@rhettinger
Copy link
Contributor

Mostly, this looks pretty good. Consider removing the peephole.c file altogether. It was originally part of compile.c and got separated out when it got too large. We can more the PyCode_Optimize() function back to compile.c. Ideally, we could drop it from the public api as part of Victor's PEP to overhaul the C API.

One small loss is that the current code has macros that provide meaningful opcode groupings like UNCONDITIONAL_JUMP, CONDITIONAL_JUMP, ABSOLUTE_JUMP, and JUMPS_ON_TRUE. I always found those grouping helpful for reasoning about the code.

Py_XINCREF(code);
PyMem_Free(blocks);
PyMem_Free(codestr);
Py_INCREF(code);
Copy link
Member

@pablogsal pablogsal Jul 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use Py_UNUSED for the ones that are not code in the function declaration.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@pablogsal pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 17, 2020
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit 6b7019a 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 17, 2020
Python/compile.c Outdated
Comment on lines 5885 to 5886
if (!names || !varnames)
goto error;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!names || !varnames)
goto error;
if (!names || !varnames) {
goto error;
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

optimize_cfg(struct assembler *a, PyObject *consts)
{
for (int i = 0; i < a->a_nblocks; i++) {
if (optimize_basic_block(a->a_reverse_postorder[i], consts)) {
Copy link
Member

@pablogsal pablogsal Jul 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this converge on one single iteration? What happens if you have a sequence of many jumps all together between blocks?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. Some jumps that can be eliminated will still remain.

This PR is aimed at closely mimicking the behavior of the existing peephole optimizer.
We can improve it later.

Copy link
Member

@pablogsal pablogsal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great and very compact! This is a very good work @markshannon ! I will do a more thorough review over the weekend but I have left some minor comments for now

@@ -3645,6 +3646,11 @@ compiler_boolop(struct compiler *c, expr_ty e)
for (i = 0; i < n; ++i) {
VISIT(c, expr, (expr_ty)asdl_seq_GET(s, i));
ADDOP_JABS(c, jumpi, end);
basicblock *next = compiler_new_block(c);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh? Why we need a new blocks here for connecting the jumps?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All instructions following a jump or branch must start a new basic block.

We now need the CFG generated by the code generation pass to be correct, as we perform jump elimination on it, rather than the CFG recreated in peephole.c.

Longer term, I think the front end should use labels and CFG creation should be a pass in between the code generation pass and the optimizer.

@markshannon markshannon force-pushed the move-peephole-optimizations-to-cfg branch from 7845d6f to 8551d33 Compare July 20, 2020 09:33
@markshannon
Copy link
Member Author

markshannon commented Jul 20, 2020

@rhettinger
I've removed peephole.c as you suggested.

The UNCONDITIONAL_JUMP, CONDITIONAL_JUMP, ABSOLUTE_JUMP, and JUMPS_ON_TRUE don't seem that useful in an instruction based optimizer.
I initially created versions of them, but it turned out they were unused. So I deleted them.
For jump-to-jump elimination, it turns out that the exact opcode is more important that whether a jump is conditional and/or relative.

@markshannon markshannon force-pushed the move-peephole-optimizations-to-cfg branch from 8551d33 to 7bc2522 Compare July 20, 2020 09:49
@markshannon markshannon requested a review from a team as a code owner July 20, 2020 09:49
}
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need one of these?

Suggested change
}
}
PyObject_Free(stack);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks.

@pablogsal pablogsal added the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 20, 2020
@bedevere-bot
Copy link

🤖 New build scheduled with the buildbot fleet by @pablogsal for commit fda0bed 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

@bedevere-bot bedevere-bot removed the 🔨 test-with-buildbots Test PR w/ buildbots; report in status section label Jul 20, 2020
@markshannon
Copy link
Member Author

One final tweak. Jumps to empty blocks that were immediately followed by jumps were not being eliminated. The final commit fixes that.

@markshannon markshannon merged commit 6e8128f into python:master Jul 30, 2020
shihai1991 pushed a commit to shihai1991/cpython that referenced this pull request Aug 4, 2020
…honGH-21517)

* Move 'peephole' optimizations into compile.c and perform them directly on the CFG.
shihai1991 pushed a commit to shihai1991/cpython that referenced this pull request Aug 20, 2020
…honGH-21517)

* Move 'peephole' optimizations into compile.c and perform them directly on the CFG.
xzy3 pushed a commit to xzy3/cpython that referenced this pull request Oct 18, 2020
…honGH-21517)

* Move 'peephole' optimizations into compile.c and perform them directly on the CFG.
@markshannon markshannon deleted the move-peephole-optimizations-to-cfg branch October 19, 2020 13:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants