Line numbers on optimized code

[Daniel Berlin <dan at cgsoftware dot com>]

Currently, the control flow they say happens is way off.

To give you an idea how weird, here's a before and after i made the
change to include the line number and filename with each insn. I
changed output_source_line to be called on each insn, instead of just
note_line_numbers, and made the approriate changes to it to handle
this.
No other logic changes were made, which is why we get thte breakpoint
address of the function wrong in the first one. It's easily
fixable, 

After is first (gcc from a few minutes ago, with my changes), before is second (gcc from the same time, no changes):


(%:/buildspace/egcs/build/gcc)- gdb ./a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...
.gdbinit:7: Error in sourced command file:
../../gcc/gdbinit.in:91: Error in sourced command file:
Function "exit" not defined.
(gdb) b main
Breakpoint 1 at 0x100004f8: file addressoftest.c, line 48.
(gdb) r
Starting program: /buildspace2/egcs/build/gcc/./a.out

Breakpoint 1, main () at addressoftest.c:48
48      }
(gdb) step
29      case APPLE: return Red;
(gdb)
48      }
(gdb)
42      snack.fred = 30;
(gdb)
45      printf("%d\n", george (&snack));
(gdb)
40      snack.variety = APPLE;
(gdb)
41      snack.shape = ROUND;
(gdb)
43      snack.george = 3;
(gdb)
44      printf("%s\n", color (&snack));
(gdb)
red
45      printf("%d\n", george (&snack));
(gdb)
3
47      printf("%d\n",  q);
(gdb)
48      }
(gdb)
46      q = snack.fred * snack.george;
(gdb)
47      printf("%d\n",  q);
(gdb) p q
$1 = 90
(gdb) step
90
48      }
(gdb)
main () at addressoftest.c:48
48      }
(gdb) q
The program is running.  Exit anyway? (y or n) y
(dberlin@debian)(168/pts)(01:10pm:06/10/01)-

(%:/buildspace/egcs/build/gcc)- gcc-3.0 -g addressoftest.c -O3 -dA -gdwarf-2
(dberlin@debian)(169/pts)(01:10pm:06/10/01)-
(%:/buildspace/egcs/build/gcc)- gdb ./a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-unknown-linux-gnu"...
.gdbinit:7: Error in sourced command file:
../../gcc/gdbinit.in:91: Error in sourced command file:
Function "exit" not defined.
(gdb) b main
Breakpoint 1 at 0x100005a8: file addressoftest.c, line 29.
(gdb) r
Starting program: /buildspace2/egcs/build/gcc/./a.out

Breakpoint 1, main () at addressoftest.c:29
29      case APPLE: return Red;
(gdb) step
37      {
(gdb)
29      case APPLE: return Red;
(gdb)
40      snack.variety = APPLE;
(gdb)
41      snack.shape = ROUND;
(gdb)
43      snack.george = 3;
(gdb)
42      snack.fred = 30;
(gdb)
37      {
(gdb)
42      snack.fred = 30;
(gdb)
45      printf("%d\n", george (&snack));
(gdb)
40      snack.variety = APPLE;
(gdb)
41      snack.shape = ROUND;
(gdb)
43      snack.george = 3;
(gdb)
44      printf("%s\n", color (&snack));
(gdb)
red
45      printf("%d\n", george (&snack));
(gdb)
3
47      printf("%d\n",  q);
(gdb)
46      q = snack.fred * snack.george;
(gdb)
47      printf("%d\n",  q);
(gdb)
90


On this very simple example, where stuff was inlined, but
no very disruptive code motion really happened, in the correct control
flow (the first  one), what we say happens, happens.

IE after snack.fred=30 appears to be executed, if you print snack,
snack.fred will be 30.

This is not so in the second one (remember, the second one is from the
same gcc cvs with just note_line_numbers, no change to keep the line
number/filename with each insn).

The 2-7 steps in the second run are bogus.
If you print the asm instructions it's executing, it's clear it's
just flat out wrong.

It's tagged the instructions as belonging to the wrong line number,
because all it has to go on is line notes.

This is why you end up with more steps to get through the program in
the second one than in the first.

Once again, no real disruptive optimizations have occurred in this
simple example.  We inlined and did some constant folding.  No
hoisting or loop stuff, no PRE moving computations, etc.
And it's still not correct.  So even in the presence of simple
optimizations, we've tagged literally 50% of the instructions with the
wrong line number when we just use line notes.  Trust me when I tell
you it's closer to 90% when a  lot of optimizations get performed,
even on 100 line examples.
With the line numbers/filenames  in the insn's, we are currently,
excluding the beginning of the function problem, tagging 0% with the
wrong line number on these same examples.  
Somewhat better.

The first example above, is completely correct, in actuality, except
for where it thinks the function is beginning.
This is because of me not yet changing the logic in final.c's
final_start_function and whatnot to DTRT for the beginning of the
function.

-- 
"I went to court for a parking ticket.  I pleaded insanity.  I
said, "Your honor, why would anyone in their right mind park in
the passing lane?"
"-Steven Wright