Computing whether an instruction is the first on a line (for tracing) in the interpreter is complicated and slow. Doing it in the compiler should be simpler and has no runtime cost.

Currently we decide if the current instruction is the first on a line, by using the `co_lines` table, but if the previous instruction executed was a jump from the same line over a block of instructions with different line number(s) then we can get this wrong.

This doesn't seem to a problem now, but could be with either: 
Specialization of FOR_ITER inlining generators, or
Compiler improvements leading to different code layout.


The table is only one bit per instruction, so shouldn't be a problem in terms of space.

I can see the linestarts used in trace.py to figure out coverage. But for this duplications don't make a difference (they are deduped in _find_lines_from_code anyway), right? 

Where else are they used, such that the current scheme may not work?

sys.settrace line events cannot use the co_lines table. They need additional state, as we don't want to trace the same line twice (unless there is a backwards jump).

Using the start of a entry in `co_lines` doesn't work when some entries have no line number.
E.g.
list(co.co_lines):

(0, 2, 1)
(2, 4, None)
(4, 6, 1)

The instruction @ byte offset 4 starts an entry for line 1, but does not start line 1.