forked from python/cpython
-
Notifications
You must be signed in to change notification settings - Fork 1
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
Register code generator #47
Closed
gvanrossum
wants to merge
478
commits into
iritkatriel:register_machine
from
gvanrossum:register-generator
Closed
Register code generator #47
gvanrossum
wants to merge
478
commits into
iritkatriel:register_machine
from
gvanrossum:register-generator
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also complete cache effects for BINARY_SUBSCR family.
… include a file extension (pythonGH-99542)
There was an extra `>` in the url.
The sentence "Set the LC_CTYPE locale to the user preferred locale." should end with a period instead of a question mark.
Add some missing links to source from Python docs
…mantics_` (pythonGH-99285) It was untested and undocumented. No code has been found in the wild that ever used it.
…them (pythonGH-99215) Automerge-Triggered-By: GH:lysnikolaou
…on protocol (pythongh-99623) Describe the multiprocessing connection protocol. It isn't a good protocol, but it is what it is. This way we can more easily reason about making changes to it in a backwards compatible way.
…ines that fill the available buffer (python#99605)
Fix a number of compile errors with GCC-12 on macOS: 1. In pylifecycle.c the compile rejects _Pragma within a declaration 2. posixmodule.c was missing a number of ..._RUNTIME macros for non-clang on macOS 3. _ctypes assumed that __builtin_available is always present on macOS
) os.remove can raise PermissionError instead of IsADirectoryError, when the object to be removed is a directory (in particular on macOS). This reverts a change done in python#14262.
Fix a reference bug in _imp.create_builtin() after the creation of the first sub-interpreter for modules "builtins" and "sys".
Co-authored-by: Kumar Aditya <59607654+kumaraditya303@users.noreply.github.com> Co-authored-by: Erlend E. Aasland <erlend.aasland@protonmail.com>
…a Python.h (pythonGH-99014) The ``structmember.h`` header is deprecated, though it continues to be available and there are no plans to remove it. There are no deprecation warnings. Old code can stay unchanged (unless the extra include and non-namespaced macros bother you greatly). Specifically, no uses in CPython are updated -- that would just be unnecessary churn. The ``structmember.h`` header is deprecated, though it continues to be available and there are no plans to remove it. Its contents are now available just by including ``Python.h``, with a ``Py`` prefix added if it was missing: - `PyMemberDef`, `PyMember_GetOne` and`PyMember_SetOne` - Type macros like `Py_T_INT`, `Py_T_DOUBLE`, etc. (previously ``T_INT``, ``T_DOUBLE``, etc.) - The flags `Py_READONLY` (previously ``READONLY``) and `Py_AUDIT_READ` (previously all uppercase) Several items are not exposed from ``Python.h``: - `T_OBJECT` (use `Py_T_OBJECT_EX`) - `T_NONE` (previously undocumented, and pretty quirky) - The macro ``WRITE_RESTRICTED`` which does nothing. - The macros ``RESTRICTED`` and ``READ_RESTRICTED``, equivalents of `Py_AUDIT_READ`. - In some configurations, ``<stddef.h>`` is not included from ``Python.h``. It should be included manually when using ``offsetof()``. The deprecated header continues to provide its original contents under the original names. Your old code can stay unchanged, unless the extra include and non-namespaced macros bother you greatly. There is discussion on the issue to rename `T_PYSSIZET` to `PY_T_SSIZE` or similar. I chose not to do that -- users will probably copy/paste that with any spelling, and not renaming it makes migration docs simpler. Co-Authored-By: Alexander Belopolsky <abalkin@users.noreply.github.com> Co-Authored-By: Matthias Braun <MatzeB@users.noreply.github.com>
Without releasing the GIL calls to termios APIs might block the entire interpreter.
…ntation (python#99529) On some platforms, and in particular macOS/arm64, the calling convention for variadic arguments is different from the regular calling convention. Add a section to the documentation to document this.
…#99655) Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" in longobject.c and _testcapi/long.c.
…unction is modified (python#98175)
Fix potential race condition in code patterns: * Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" * Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);" * Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);" Other changes: * Replace "old = var; var = new; Py_DECREF(var)" with "Py_SETREF(var, new);" * Replace "old = var; var = new; Py_XDECREF(var)" with "Py_XSETREF(var, new);" * And remove the "old" variable.
Fix potential race condition in code patterns: * Replace "Py_DECREF(var); var = new;" with "Py_SETREF(var, new);" * Replace "Py_XDECREF(var); var = new;" with "Py_XSETREF(var, new);" * Replace "Py_CLEAR(var); var = new;" with "Py_XSETREF(var, new);" Other changes: * Replace "old = var; var = new; Py_DECREF(var)" with "Py_SETREF(var, new);" * Replace "old = var; var = new; Py_XDECREF(var)" with "Py_XSETREF(var, new);" * And remove the "old" variable.
Replace "Py_XDECREF(var); var = NULL;" with "Py_CLEAR(var);". Don't replace "Py_DECREF(var); var = NULL;" with "Py_CLEAR(var);". It would add an useless "if (var)" test in code path where var cannot be NULL.
…ongh-100203) We can't move it to _PyRuntimeState because the symbol is exposed in the stable ABI. We'll have to sort that out before a per-interpreter GIL, but it shouldn't be too hard. python#81057
…python#100177) pythongh-100176: Remove redundant compat code for Python 3.2 and older Python 3.2 has been EOL since 2016-02-20 and 2.7 since 2020-01-01, so we can remove this old compatibility check and unindent the old else-block. Also, in the unindented block, replace a .format() call with an f-string. Plus similar changes in the documentation.
…0254) * move _PyRuntime.global_objects.interned to _PyRuntime.cached_objects.interned_strings (and use _Py_CACHED_OBJECT()) * rename _PyRuntime.global_objects to _PyRuntime.static_objects (This also relates to pythongh-96075.) python#90111
…9998) * Initialize `type_watchers` array to `NULL`s * Optimize code watchers notification * Optimize func watchers notification
…100259) Typo introduced in python#100223. Automerge-Triggered-By: GH:brandtbucher
Obviously there's a git issue. I can sort it out later. The key thing is just the last commit. |
… input (python#100205) The presence of this macro indicates that a particular instruction may be considered for conversion to a register-based format (see faster-cpython/ideas#485). An invariant (currently unchecked) is that `DEOPT_IF()` may only occur *before* `DECREF_INPUTS()`, and `ERROR_IF()` may only occur *after* it. One reason not to check this is that there are a few places where we insert *two* `DECREF_INPUTS()` calls, in different branches of the code. The invariant checking would have to be able to do some flow control analysis to understand this. Note that many instructions, especially specialized ones, can't be converted to use this macro straightforwardly. This is because the generator currently only generates plain `Py_DECREF(variable)` statements, and cannot generate things like `_Py_DECREF_SPECIALIZED()` let alone deal with `_PyList_AppendTakeRef()`.
I updated only UNARY_POSITIVE_R to the new format. - Syntax `register inst(NAME, (ieffects -- oeffects)) { ... }` - Map stack effects from/to `REG(opargN)` instead of PEEK() - Use `Py_XSETREF(REG(opargN), result)` for output effects - Suppress stack adjustment in epilogue - Suppress effect of `DECREF_INPUTS()` - Always go to plain `error` in `ERROR_IF()`
gvanrossum
force-pushed
the
register-generator
branch
from
December 17, 2022 19:55
93357f6
to
f703a9c
Compare
Let me close this and create a new PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Here's a sketch of how to generate glue for register instructions. Lightly tested.