Consider func rewriteBlockAMD64. It spans lines 66518-69626 of rewriteAMD64.go. However, it calls (at line 66699) func log2, located at lines 369-370 of rewrite.go. log2 is inlined. Thus when the numberLines pass looks for the first and last lines of func rewriteBlockAMD64, it doesn't find lines 66518-69626, it finds lines 369-69626! It then allocates a giant sparsemap to accomodate all these lines.

This is currently causing toolspeed pain; allocating those sparsemaps accounts for ~17% of the allocated space when compiling the ssa package. (The ssa package has many long files with many functions that inline functions with small line numbers.) Related: #27739.

(This also makes me nervous about whether we're correctly handling one function that inlines another when both functions happen to occupy the same line numbers, but in different files. I assume @dr2chase can speak to that without having to go spelunking.)

I don't know what the correct fix is, but we remove the implicit assumption that the line numbers involved in a function are dense.

Marking as Go 1.12 to match #27739, but it seems to me that we can probably push to 1.13.