cmd/compile: better XPos for rematerialized values and JMPs
This attempts to choose better values for values that are rematerialized (uses the XPos of the consumer, not the original) and for unconditional branches (uses the last assigned XPos in the block). The JMP branches seem to sometimes end up with a PC in the destination block, I think because of register movement or rematerialization that gets placed in predecessor blocks. This may be acceptable because (eyeball-empirically) that is often the line number of the target block, so the line number flow is correct. Added proper test, that checks both -N -l and regular compilation. The test is also capable (for gdb, delve soon) of tracking variable printing based on comments in the source code. There's substantial room for improvement in debugger behavior. Updates #21098. Change-Id: I13abd48a39141583b85576a015f561065819afd0 Reviewed-on: https://go-review.googlesource.com/50610 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Showing
This diff is collapsed.
Please
register
or
sign in
to comment