Thanks, Irit for your comment!

Is it really every instruction? Or only those that can raise exceptions?

Technically only the ones that can raise exceptions, but the majority can and optimizing this to only restrict to the set that can raise exceptions has
the danger than the mapping needs to be maintained for new instructions and that if some instruction starts raising exceptions while it didn't before
then it can introduce subtle bugs.

On the other hand I think the stronger argument to do this on every instruction is that there is a lot of tools that can find this information quite useful
such as coverage tools, profilers, state inspection tools and more. For example, a coverage tool will be able to tell you what part of

x = f(x) if g(x) else y(x)

actually was executed, while currently, it will highlight the full line. Although in this case these instructions can raise exceptions and would be covered,
the distinction is different and both criteria could lead to a different subset.

In short, that may be an optimization but I think I would prefer to avoid that complexity taking into account the other problems that can raise and the extra complication

On Fri, 7 May 2021 at 23:21, Irit Katriel <iritkatriel@googlemail.com> wrote:


On Fri, May 7, 2021 at 10:52 PM Pablo Galindo Salgado <pablogsal@gmail.com> wrote:

The cost of this is having the start column number and end column number information for every bytecode instruction


Is it really every instruction? Or only those that can raise exceptions?