On 10/16/19 5:59 AM, Richard Biener wrote:
I think that adding an extra jump is unwanted. Instead - if you disregard the single-source-line case - there's always the jump and the label we jump to which might/should get different source locations. Like in one of the above cases:main () { int D.1803; [t.c:2:1] { int var; [t.c:3:5] var = 0; <D.1801>: [t.c:7:8] var = var + 1; [t.c:7:8] goto <D.1801>; [t.c:10:8] D.1803 = 0; [t.c:10:8] return D.1803; seen at GIMPLE. Of course we lose the label once we build the CFG, but we retain a goto-locus which we could then put back on the jump statement. For this case we at the moment get .L2: .loc 1 7 0 discriminator 1 addl $1, -4(%rbp) jmp .L2 and we could do .L2: .loc 1 7 0 discriminator 1 addl $1, -4(%rbp) .loc 1 5 0 jmp .L2 thus assign the "destination" location to the jump instruction?
On a first look, i considered reusing the jump instruction that did not get a location assigned to it, but that didn't work right for all cases, such as the one you showed below with the incorrect line ordering.
The first question is of course what happens with the edges goto_locus at the moment and why we get the code we get. The above solution might also be a bit odd since for the loop entry we'd first see line 7 and only after that line 5. But fixing that would mean we have to output an extra instruction (where I'd chose a nop instead of some random extra jump).
Right. I wanted to preserve the correct order of execution, at least from a O0 perspective. A nop would work just as well. I'll give this a try.
I don't think it makes sense to output additional instructions in O1+ cases just because we want to have more debug info, but we do need a new instruction address in some cases, in order to use it in the line table for the line transition.
Would it make sense to have it restricted to O0?
