[issue45757] compiler emits EXTENDED_ARG + NOP sequence in 3.10

2021-11-10 Thread Brandt Bucher
Brandt Bucher added the comment: Here's a (more) minimal reproducer I've been able to create: ``` # First, "use up" 256 unique constants: spam=0x00;spam=0x01;spam=0x02;spam=0x03;spam=0x04;spam=0x05;spam=0x06;spam=0x07; spam=0x08;spam=0x09;spam=0x0a;spam=0x0b;spam=0x0c;spam=0x0d;spam=0x0e;spam=

[issue45757] compiler emits EXTENDED_ARG + NOP sequence in 3.10

2021-11-09 Thread Irit Katriel
Irit Katriel added the comment: That sounds like a good idea. Please go ahead. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue45757] compiler emits EXTENDED_ARG + NOP sequence in 3.10

2021-11-09 Thread Brandt Bucher
Brandt Bucher added the comment: Indeed. Do you plan on removing the extra EXTENDED_ARGs in instrsize and write_op_arg? I can take care of it if not. -- ___ Python tracker __

[issue45757] compiler emits EXTENDED_ARG + NOP sequence in 3.10

2021-11-09 Thread Irit Katriel
Irit Katriel added the comment: > I don't think that it does, since oparg gets totally reassigned each time > we load a new instruction. EXTENDED_ARG actually needs to hack around > this by advancing the instruction itself, updating oparg, and jumping > straight into the next opcode. Right, it