[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: I implemented it ages ago :) https://github.com/python/cpython/pull/24417 I need to be better at closing issues. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Ethan Furman added the comment: Mark, it looks like the consensus is your proposal: "The implementation is allowed to skip any boolean test of a value, when it has *no* effect on the flow of the program and *at least one test* has already been performed on that value." Has the

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: I don't care about the flipflop at all. I only care about the third possible outcome, an exception. I thought the compromise semantics you proposed earlier sounded nice. As Serhiy already explained, 'b or True' vs. 'True or b' is unrelated. --

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Change by Mark Shannon : -- keywords: +patch pull_requests: +23232 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24417 ___ Python tracker ___

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: It isn't a specific optimization at all, but the combination of several. I will change the behavior to match what appears to be the consensus. BUT, we need to define what the semantics should be. Otherwise implementing the compiler is just guesswork. As for

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Serhiy Storchaka added the comment: `True or b` is always True and differs from `b or True`. `x = True and y` is always equivalent to `x = y`. What is the use case of your optimization? Can you provide examples of real code which would benefit from removing all boolean tests (not only the

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: Option 3 with what semantics exactly? https://docs.python.org/3/reference/datamodel.html#object.__bool__ says that __bool__ should return True or False. If we don't allow the optimizer the freedom to assume that __bool__ is self-consistent and has no side

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: I still favor (3) -- I don't want to renege on the promise we made when we allowed overloading comparisons to return something other than a bool. -- ___ Python tracker

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The differences between allowing the optimiser to remove truly redundant (in terms of control flow) boolean tests, or not, is slight. It only matters for __bool__() calls that have side effects. Like __hash__(), __bool__() should not produce side effects.

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Pablo Galindo Salgado added the comment: Mark, what is the status of this issue? This is marked as a release blocker so I would prefer not to release the next alpha with this being unfixed. -- ___ Python tracker

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: > "The implementation is allowed to skip any boolean test of a value, when it > has *no* effect on the flow of the program and at least one test has already > been performed on that value." +1 -- ___ Python

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: Sounds great to me (with my approximately zero optimizer experience) At risk of taking this too far, you /could/ add something like: "skip any boolean test of a value _immediately_ following another boolean test, when it has no ..." to this

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: I missed a "no" in the above, which somewhat changed the meaning! It should have read: "The implementation is allowed to skip any boolean test of a value, when it has *no* effect on the flow of the program and at least one test has already been performed on

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The problem with using a specific syntax example, is that the optimizer doesn't work that way. It works on the CFG. Any specification needs to be phrased in terms of general control flow, as other optimizations can enable this transformation. e.g. if x or

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: Is anyone still in favor of eliminating the __bool__ call from ‘if p: pass’? -- ___ Python tracker ___

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: Oops, sorry, didn't realise there were such rules. The reasoning for me making the change to the title is that that the original PR didn't mention skipping actual condition logic, but does mention skipping unreachable blocks, with the examples provided

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Change by Mark Shannon : -- title: Is it legal to eliminate tests of a value, when that test has no effect on control flow -> Is it legal to eliminate tests of a value, when that test has no effect on control flow? ___ Python tracker

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow

Mark Shannon added the comment: Steve, Please don't change the title of the issue. Sure, the optimizer is "inconsistent". Optimizations are applied in some cases, and not in others. That's just how compilers work. The issue here is whether the optimizer is allowed to skip the call to

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Josh Rosenberg added the comment: Gregory: Even in a low-level compiled language (say, C++), pretty sure the compiler can't automatically optimize out: if (x) { } unless it has sure knowledge of the implementation of operator bool; if operator bool's implementation isn't in the header

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: Hm, I hadn't realized the issue of bool(a) being evaluated once or twice. The most important side effect that bool(a) can have is raising (as e.g. numpy arrays do), not producing random results. Another important side effect might be loading some value

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Gregory P. Smith added the comment: If the body of a conditional does nothing, it seems fine to optimize the condition out to me. But I see code from a low level compiled language perspective where that is clearly what would happen. In reality, who ever meaningfully writes code where the

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: > How do we know `x` is falsey without calling `bool()` on it? We don't, but in `if x: pass`, it doesn't matter. Discounting side-effects in __bool__, the code does nothing regardless of the value of `x`. -- ___

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: It's clearer if you rewrite if a and b: ... as tmp = a and b if tmp: ... if a is falsey then bool(a) gets called in `tmp = a and b` and `a` is assigned to `tmp`. Then in `if tmp`, bool(a) is called again. I agree with you about it not being an

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Ethan Furman added the comment: If an optimization changes semantics it's not an optimization. In `if x: pass` how do we know `x` is falsely without calling `bool()` on it? --- On a slightly different note, in the code: if a and b: ... why is `bool(a)` called twice?

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Change by Mark Shannon : -- priority: normal -> release blocker ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: They aren't quite the same. If `a` is falsey, and bool(a) has a side-effect, then that side-effect should occur twice in: if a and b: ... but only once in if a: if b: ... It gets more interesting (silly), if `a.__bool__()` alternated between

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Guido van Rossum added the comment: Can we translate 'if x: pass' into 'pass'? No, because calling its __bool__ method may have a side effect (as we saw at the start of this thread). Can we eliminate a lone 'x'? Only if it's a local variable and we're *sure* (because of control flow

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Serhiy Storchaka added the comment: For the latter, it was decided that it is legal a long time ago. It has a benefit and we did not have any complains for all these years. The absent of this optimization would encourage writing less readable code for performance. For the former, what is

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The question still stands. Is converting `if x: pass` to `pass` legal? And, if it is not, is converting if a and b: body to if a: if b: body a legal transformation? (ignoring line numbers) If the first transformation is not allowed but

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Serhiy Storchaka added the comment: Thank you Steve. Yes, this is what I meant. "if a and b" is so common that we sacrifice literal translation for the sake of performance. "if" with an empty block looks pretty uncommon to me. It is not worth to optimize this case specially (especially if

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: I got my and/or logic inverted, but believe the point still stands -- ___ Python tracker ___ ___

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Steve Stagg added the comment: To be super pedantic, as per my understanding of: "6.11 ... The expression x and y first evaluates x; if x is false, its value is returned; otherwise, y is evaluated and the resulting value is returned." The only corner that was previously cut is that in this

[issue42899] Is it legal to eliminate tests of a value, when that test has no effect on control flow?

Mark Shannon added the comment: The issue here is: Is it legal to convert if x: pass into pass ? The explicit effect of the code is unchanged, BUT the implicit effect (of calling x.__bool__) is changed. The examples Serhiy gives are similar. If `bool(a)` evaluates to False, then