Debugging information problem: code being reordered / debug point jumping around

I'm seeing some undesirable behavior where, when generating debugging information, sometimes the point in the debugger will jump forwards and backwards during single stepping, even though the output from our frontend (this is the ispc compiler), is emitting LLVM instructions with a strictly forward-moving/increasing set of source locations. I'm wondering if we're doing something wrong here, or if this points to a bug somewhere in LLVM.

I've attached a case that demonstrates this. Specifically, the instructions in the LLVM assembly language for the foo() function have the following metadata items associated with them, in the following order: 5519, 5520, 5522, 5523, 5524, 5525, 5526, 5527, 5528, 5529, 5530, 5531, 5532, 5533, 5534, 5521. These correspond to the source file locations: [4,22], [5,5], [5,11], [5,22], [5,23], [6,14], [6,22], [6,24], [6,26], [8,11], [8,15], [9,9], [9,10], [9,11], [10,12], [10,12]. ([line, column]).

However, if I run "llc -O0 debug.ll -o debug.s" with top of tree, the set of source locations indicated in comments jumps from [5,23] to [9,10], and then back to [6,22]. (And if I single-step through this code in gdb, I see the corresponding jump around.)

I'd be happy to hear any comments or suggestions!

Thanks,
-matt

debug.ll.gz (65.2 KB)

What do you see after instruction select ?
I'll take a look at this. Meanwhile, please file bugzilla report so that this does not get lost.

What do you see after instruction select ?

Good question–I just checked. Things are still in the right order going into the x86 DAG->DAG instruction select pass, but then are out of order coming out of it. So that looks like the culprit…

I’ll take a look at this. Meanwhile, please file bugzilla report so that this does not get lost.

Thanks. http://llvm.org/bugs/show_bug.cgi?id=10550

-matt

What do you see after instruction select ?

Good question–I just checked. Things are still in the right order going into the x86 DAG->DAG instruction select pass, but then are out of order coming out of it. So that looks like the culprit…

If fast-isel bails then SelectionDAG does not guarantee to preserve source order (even at -O0), SelectionDAG only commits best effort to preserve line numbers.

I’ll take a look at this. Meanwhile, please file bugzilla report so that this does not get lost.

Thanks. http://llvm.org/bugs/show_bug.cgi?id=10550

Thanks!