[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46808] remove NEXT_BLOCK() from compile.c

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46808] remove NEXT_BLOCK() from compile.c

[Mark Shannon]

Mark Shannon  added the comment:


New changeset c579243eb62d3182c84004cd72dcf6ef59100643 by Irit Katriel in 
branch 'main':
bpo-46808: remove NEXT_BLOCK() from compile.c (GH-31448)
https://github.com/python/cpython/commit/c579243eb62d3182c84004cd72dcf6ef59100643


--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

Irit Katriel  added the comment:

The patch in PR31448 delays the creation of an implicit block to when it is 
needed (do if we begin using another block before a new instruction is added, 
the implicit block is never created). 

I counted how many empty blocks are being detected by the optimizer during 
"python -m test" and this number went down from 41798 (for main) to 35405 (for 
my PR), which shows that it is not only a theoretical possibility but actually 
happens. It would be things like:

NEXT_BLOCK()
VISIT_SEQ(c, stmt, s->v.Try.orelse);
compiler_use_next_block(c, end);

where the orelse block is empty.


In summary, the patch simplifies the code as well as making it more efficient.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

Change by Irit Katriel :


--
keywords: +patch
pull_requests: +29576
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31448

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46808] remove NEXT_BLOCK() from compile.c

[Irit Katriel]

New submission from Irit Katriel :

The compiler currently requires the code-generation functions to explicitly 
specify where basic blocks end, with a NEXT_BLOCK().

If you get that wrong, you get an exception about "malformed control flow 
graph" later, in the cfg analysis stage. It is not obvious then where the error 
is, and it makes it difficult to make changes in the compiler. 

We can instead make the compiler implicitly create a new block when this is 
needed (which is after specific opcodes).

--
assignee: iritkatriel
components: Interpreter Core
messages: 413589
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: remove NEXT_BLOCK() from compile.c
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com