I noticed that in functions like:

package main

import "runtime"

var sink *int

func f(x, y int) int {
    sink = &x
    runtime.GC()
    return x + y
}

The evaluation of x on line 10 gets assigned different line numbers by SSA and by the legacy compiler. SSA gives the evaluation of "x" line 7:

    0x004b 00075 (/home/khr/go/tmp5.go:7)   MOVQ    "".&x+16(SP), CX
    0x0050 00080 (/home/khr/go/tmp5.go:7)   MOVQ    (CX), CX

The legacy compiler gives it line 10:

    0x004a 00074 (/home/khr/go/tmp5.go:10)  MOVQ    "".&x+16(SP), BX
    0x004f 00079 (/home/khr/go/tmp5.go:10)  MOVQ    (BX), BX

The reason is that after walk, in the statement "return x + y" the line numbers of "return" and "+" are 10 but the line numbers of "x" and "y" are 7. SSA is using the deepest line number it can lay its hands on, so when evaluating "x" it uses line 7 for the instructions that evaluate "x".

The legacy compiler seems to use the line number of the containing statement (as far as I can tell). Modifying the SSA compiler to do the same (ignoring line numbers on expressions) makes SSA produce similar output to the legacy compiler.

Under more complicated examples, SSA can tend to jump back and forth between the line numbers of the variable declarations and the line numbers where those variables are used. That seems suboptimal. It would be clearer (and compress better) if the line numbers were all from the use points.

I don't think we can fix walk's output, as all the "x"s in the function are aliased to the same Node, so they can only have 1 line number. Maybe we just ignore line numbers from ONAMEs? (i.e. they inherit their line number from their parent in the AST)

@dr2chase