Redundant `LINENUMBER` opcodes may be removed

[yegor256]

This is the bytecode for my Java method:

  // access flags 0x1
  public plain()J
  @Lorg/openjdk/jmh/annotations/Benchmark;()
   L0
    LINENUMBER 62 L0
    LCONST_0
    LSTORE 1
   L1
    LINENUMBER 63 L1
    ICONST_0
    ISTORE 3
   L2
   FRAME APPEND [J I]
    ILOAD 3
    GETSTATIC org/eolang/benchmark/Big.VALUES : [Ljava/lang/Object;
    ARRAYLENGTH
    IF_ICMPGE L3
   L4
    LINENUMBER 64 L4
    GETSTATIC org/eolang/benchmark/Big.VALUES : [Ljava/lang/Object;
    ILOAD 3
    AALOAD
    CHECKCAST java/lang/String
    INVOKEVIRTUAL java/lang/String.trim ()Ljava/lang/String;
    ASTORE 4
   L5
    LINENUMBER 65 L5
    ALOAD 4
    INVOKEVIRTUAL java/lang/String.length ()I
    ICONST_4
    IF_ICMPEQ L6
   L7
    LINENUMBER 66 L7
    GOTO L8
   L6
    LINENUMBER 68 L6
   FRAME APPEND [java/lang/String]
    LLOAD 1
    ALOAD 4
    BIPUSH 16
    INVOKESTATIC java/lang/Long.parseLong (Ljava/lang/String;I)J
    LCONST_1
    LADD
    LADD
    LSTORE 1
   L8
    LINENUMBER 63 L8
   FRAME CHOP 1
    IINC 3 1
    GOTO L2
   L3
    LINENUMBER 70 L3
   FRAME CHOP 1
    LLOAD 1
    LRETURN
   L9
    LOCALVARIABLE str Ljava/lang/String; L5 L8 4
    LOCALVARIABLE idx I L2 L3 3
    LOCALVARIABLE this Lorg/eolang/benchmark/Big; L0 L9 0
    LOCALVARIABLE acc J L1 L9 1
    MAXSTACK = 6
    MAXLOCALS = 5

I see many LINENUMBER opcodes (actually, one per every Java line), which are not necessary and may easily be eliminated before translating this code to XMIR. This will simplify XMIR and increase its readability (and speed of processing).

[volodya-lombrozo]

@yegor256 We don't save line numbers in XMIR representation. We have it only in the listing element (that exists only for informational purposes)

[yegor256]

@volodya-lombrozo we convert LINENUMBER opcodes to labels:

               <o base="jeo.label"><!-- L610874314 -->
                  <o base="org.eolang.bytes" data="bytes">61 32 30 34 31 32 61 64 2D 38 32 39 65 2D 34 63 31 63 2D 62 64 66 62 2D 66 32 34 33 30 32 39 63 65 39 66 34</o>
               </o>

Right?

[volodya-lombrozo]

@yegor256 Indeed. You are almost right. Actually, we have both of them: 1) line numbers and 2) labels. We don't convert line numbers to labels. We have both of them independently. Usually labels serve as target points for other jump instructions, for example as for goto in your example:

L2
...
GOTO L2

But sometimes, there are labels that are only targets for lines:

L0
...
LINENUMBER 62 L0

We can try to remove these labels that are used only by line entries, and it will indeed reduce the size of xmir and might even speed up the entire pipeline a bit. However, I’m afraid that, in this case, we might need to perform an analysis that could negate the possible performance boost. At least I can try.

[yegor256]

@volodya-lombrozo if GOTO is the only opcode that uses labels, it seems, you can easily (and quickly) find unused labels

[volodya-lombrozo]

@yegor256 Labels might be used by try-catch statements as well. The exception table is placed separately from the instructions set. This might complicate things a bit. Moreover, labels might serve some other purposes which we don't see for now. I will try to do to remove such labels. But, please, don't underestimate the problem:

you can easily (and quickly) find unused labels

We don't know yet.

[0pdd]

@yegor256 the puzzle #893 is still not solved.

[volodya-lombrozo]

@rultor release, tag is 0.6.20, title is 0.6.20

[rultor]

@rultor release, tag is 0.6.20, title is 0.6.20

@volodya-lombrozo OK, I will release it now. Please check the progress here.

[rultor]

@rultor release, tag is 0.6.20, title is 0.6.20

@volodya-lombrozo Done! FYI, the full log is here (took me 17min).

[volodya-lombrozo]

@yegor256 Would you mind trying the new 0.6.20 version, please?

[volodya-lombrozo]

@yegor256 friendly reminder

[0pdd]

@yegor256 the only puzzle #893 is solved here.

[yegor256]

@volodya-lombrozo it's much better now, thanks!