GH-125837: Split LOAD_CONST into three.
#125972
Conversation
Co-authored-by: Tomas R. <tomas.roun8@gmail.com>
I think the range is -5 -> 256 (included) right? (at least _PyLong_SMALL_INTS works that way, but maybe 256 should be excluded even though it's stored in the _PyLong_SMALL_INTS). |
I want We can always add -5,-4,-3,-2 and -1 to |
|
Performance for tier 1 appears to be about 0.5% faster. Stats show the following fraction of constants loaded:
With a reduction in increfs of immortal objects of about 20%. |
markshannon
requested review from
Eclips4,
ericsnowcurrently,
brettcannon,
ncoghlan and
warsaw
as code owners
markshannon
requested review from
Fidget-Spinner and
iritkatriel
as code owners
| Adds :opcode:`LOAD_INT` and :opcode:`LOAD_CONST_IMMORTAL` instructions. | ||
| ``LOAD_INT`` pushes a small integer equal to the ``oparg`` to the stack. | ||
| ``LOAD_CONST_IMMORTAL`` does the same as ``LOAD_CONST`` but is more | ||
| efficient for immortal objects. |
| @@ -656,6 +664,9 @@ codegen_setup_annotations_scope(compiler *c, location loc, | |||
| codegen_enter_scope(c, name, COMPILE_SCOPE_ANNOTATIONS, | |||
| key, loc.lineno, NULL, &umd)); | |||
|
|
|||
| // Insert None into consts to prevent an annotation | |||
| // appearing to be a docstring | |||
| _PyCompile_AddConst(c, Py_None); | |||
There was a problem hiding this comment.
What does this have to do with this PR?
There was a problem hiding this comment.
The consts for an __annotate__ function could be (0, "a_string"). Removing the 0 makes "a_string" the doc string.
Python/flowgraph.c
Outdated
| @@ -2173,7 +2155,8 @@ remove_unused_consts(basicblock *entryblock, PyObject *consts) | |||
|
|
|||
| for (basicblock *b = entryblock; b != NULL; b = b->b_next) { | |||
| for (int i = 0; i < b->b_iused; i++) { | |||
| if (OPCODE_HAS_CONST(b->b_instr[i].i_opcode)) { | |||
| int opcode = b->b_instr[i].i_opcode; | |||
| if (OPCODE_HAS_CONST(opcode) && opcode != LOAD_SMALL_INT) { | |||
There was a problem hiding this comment.
hasconst is defined in the dis docs as "Sequence of bytecodes that access a constant". I think it will make more sense if we clarify that it means "access a constant from co_consts" and then remove LOAD_SMALL_INT from hasconst and OPCODE_HAS_CONST.
There was a problem hiding this comment.
That makes sense. LOAD_COMMON_CONST is not in hasconst.
There was a problem hiding this comment.
Maybe it's worth testing whether creating integers within the range(256) will not affect co_consts?
…om code.co_consts
| consts.append(instr.argval) | ||
| return consts | ||
|
|
||
| @support.cpython_only | ||
| def test_load_const(self): | ||
| consts = [None, | ||
| True, False, | ||
| 124, |
There was a problem hiding this comment.
Can we replace it with an int which is not captured by LOAD_SMALL_INT instead of removing it? For example, 1000.
Splits
LOAD_CONSTinto three instructionsLOAD_INTfor ints inrange(256). Avoids the need for a space in theco_conststuple and avoids an increfLOAD_CONST_IMMORTALfor other immortal objects. Avoids an increfLOAD_CONSTfor the remaining constantsRETURN_VALUEandRETURN_CONST#125837📚 Documentation preview 📚: https://cpython-previews--125972.org.readthedocs.build/