Commit 9a7e70e3 authored by David Chase's avatar David Chase

cmd/compile: schedule OpArg earlier in blocks for better debugging

The location list for OpArg starts where the OpArg appears;
this is not necessarily as soon as the OpArg coulde be
observed, and it is reasonable for a user to expect that
if a breakpoint is set "on f" then the arguments to f will
be observable where that breakpoint happens to be set (this
may also require setting the breakpoint after the prologue,
but that is another issue).

Change-Id: I0a1b848e50f475e5d8a5fad781241126872a0400
Reviewed-on: https://go-review.googlesource.com/c/142819
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarHeschi Kreinick <heschi@google.com>
Reviewed-by: 's avatarAlessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
parent bdba5565
......@@ -8,6 +8,7 @@ import "container/heap"
const (
ScorePhi = iota // towards top of block
ScoreArg
ScoreNilCheck
ScoreReadTuple
ScoreVarDef
......@@ -113,6 +114,9 @@ func schedule(f *Func) {
case v.Op == OpVarDef:
// We want all the vardefs next.
score[v.ID] = ScoreVarDef
case v.Op == OpArg:
// We want all the args as early as possible, for better debugging.
score[v.ID] = ScoreArg
case v.Type.IsMemory():
// Schedule stores as early as possible. This tends to
// reduce register pressure. It also helps make sure
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment