-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: increased line number churn #20367
Comments
Working on it, the problem comes from a poor combination of positioning "SB" (and "SP" and initial memory) and not positioning the LEAQ itself, which causes it to inherit the predecessor (SB) line number. Minimal fix is to use src.NoXPos entryNewValue0, was wondering if it might not make more sense to use that for all the entryNewValueX generators. The reason for doing the larger-scope "fix" is that each of the entryNewValueX calls will stuff a "random" line number into the values in the entry Block (i.e., nonsensical for debugging), though the values so stuffed are all of the sort that get sunk down closer to their uses, which may or may not match their definitions. |
It certainly makes sense to use src.NoXPos for things like OpSP.
It would be nice if the LEAQ had the line number of the return instruction, not the func declaration. |
Hmm. Tangent, but when we CSE values, which line number do we pick? Should we switch to NoXPos when we CSE two values from different lines? |
CSE chooses a value which dominates all the others in its equivalence class. Within a block, it is an arbitrary choice. |
CL https://golang.org/cl/43531 mentions this issue. |
This problem has always existed with the SSA backend and my impression is that it got better during go1.9 development windows, however a recent commit, 00263a8, while trying to improve the situation actually made some things worse (although I'm sure it did actually improve numbering in other circumstances). For example in this program the function main.helloworld went from compiling (with -gcflags='-N -l') to:
To compiling to:
Note the line number of the LEA at 0x481b5f, there multiple examples of this happening in delve's test set.
cc @dr2chase
The text was updated successfully, but these errors were encountered: