GH-130415: Narrow str to "" based on boolean tests
#130476
Conversation
|
All commit authors signed the Contributor License Agreement. |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
brandtbucher
added
performance
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
|
Added requested corrections. Thanks, @brandtbucher ! |
Lib/test/test_capi/test_opt.py
Outdated
| dummy = "aaa" | ||
| # Hopefully the optimizer can't guess what the value is. | ||
| # empty is always "", but we can only prove that it's a string: | ||
| empty = dummy[:0] |
There was a problem hiding this comment.
I can easily see the optimizer turning "aaa"[:0] into "".
empty doesn't need to be a constant, we just need it to be mostly "", for profiling.
Use something like empty = "a"[:(n % 1000) == 0]
There was a problem hiding this comment.
Since we check the actual path taken as part of the test, we need the value to always be "", not just mostly "". So maybe:
false = i == TIER2_THRESHOLD
empty = "X"[:false]The optimizer can't prove false is False, so it's good enough for our purposes.
Python/optimizer_bytecodes.c
Outdated
| // *can't* narrow res, since that would cause the guard to be | ||
| // removed and the narrowed value to be invalid: | ||
| if (next_opcode == _GUARD_IS_FALSE_POP) { | ||
| sym_set_const(value, Py_GetConstant(Py_CONSTANT_EMPTY_STR)); |
There was a problem hiding this comment.
This is strictly incorrect. We don't know that value is "" until after the _GUARD_IS_FALSE_POP.
The reason that matters is that when we start attaching type information to side exits, as we probably will in 3.15, then this could lead us to infer that value is "" on both branches. Which would be wrong.
There are two possible fixes for this.
- Combine
TO_BOOL_STRand_GUARD_IS_FALSE_POP/_GUARD_IS_TRUE_POPinto a single (super)instruction, then optimize that. - Annotate the bool value resulting from the
TO_BOOLwith its input, then in_GUARD_IS_FALSE_POPconvert the input value toTO_BOOL.
I prefer the second option, although it may be more work, as it is more flexible and can be extended more easily.
There was a problem hiding this comment.
Yeah, @Fidget-Spinner and I suggested something like the latter on the issue (new symbols like JitBoolOf(JitOptSymbol *source, bool inverted) and JitEqualTo(JitOptSymbol *lhs, JitOptSymbol *rhs, bool inverted)). That's probably the direction we're headed in longer term.
However, I don't think we should let perfect be the enemy of good here. We have nice, working optimizations in these PRs; just because we might sink info onto side exits in the future probably shouldn't prevent us from making changes like this now for 3.14, which are perfectly correct for the current optimizer (which doesn't sink anything).
I'm inclined to land these changes and other similar ones for ==/!= now, and make the symbolic representation of derived boolean values more complex later as an improvement (it will also be able to handle more uncommon cases like x = y == 42; if x: ...). I'm really worried that if we try to "future-proof" optimizations based on what we could do six months from now, it will prevent actual improvements in the near term.
But I'll defer to you here. If having value be narrowed one uop too early in the instruction stream is enough to block this PR, I can work with these new contributors on the more complex solution. But as-is, this has no bugs and works as intended. We don't sink value info onto side exits, so it's correct.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
brandtbucher
changed the title
str to "" based on boolean tests
Assign value to string when an
ifevaluates to false.@brandtbucher