cmd/compile: do more aggressive rewrites during constant evaluation

[josharian]

CL 37499 taught the inliner to ignore dead code when inlining. There's a similar CL for escape analysis. And then CL 38601 did the same thing for the exporter. Three is too many--and all three would have to be remembered if, for example, we checked for for false { ... } as well as if false { ... }.

Instead, when we constant evaluate an OIF Node's n.Left to a constant bool, we should update the OIF's parent statement list.

Statement list before:

OIF n.Ninit; n.Left { n.Nbody } else { n.Rlist }

And after:

n.Ninit; _ = n.Left; n.Rlist or n.Nbody as appropriate

Then we can unwind all the other changes.

This might be tricky, since we might not have convenient access to the parent statement list to update it. (Related, kinda: #17108.)

cc @griesemer

[mdempsky]

One option is to rewrite the OIF Node into an OBLOCK Node, like how evconst works.

Alternatively, since we're doing constant folding in typecheck anyway, we can probably just return the new OBLOCK Node and the caller will update references appropriately.

[josharian]

Good call. Seems pretty approachable for someone with low to moderate compiler experience, so added HelpWanted.

[mdempsky]

A caveat of either approach though is we need to be careful about goto/label handling. This needs to remain valid:

label:
if false { goto label }

and this needs to remain invalid:

if false { unused: goto invalid }
var x int
invalid:

[josharian]

Such things are rare enough that it's probably ok to just inhibit dead code elimination if labels or gotos are present inside the relevant blocks.

[josharian]

It's also entirely possible that (valid) labels/gotos inside apparently dead code like that is currently mishandled by the compiler. Moving to 1.9.

[dr2chase]

My solution to this annoying problem when I rewrote for-range loops for backedge rescheduling was to add another node with the same AST shape as the one transformed, but slightly different semantics. I.e., OIF, OIF_FALSE (== if(false)), OIF_TRUE (== if(true)). I suspect that this is ugly, but the other approaches I tried for dealing with label checking were uglier.

[mdempsky]

We could potentially do goto validating in the frontend during type checking. Any gotos/labels introduced during order/walk would not get validated though.

[josharian]

Any gotos/labels introduced during order/walk would not get validated though.

That's ok.

We could potentially do goto validating in the frontend during type checking.

It's not just validation. I'm also worried about valid things like:

  i := 0
  if false {
    mutate:
       i++
  }
  if i == 0 {
    goto mutate
  }
  println(i)

If we constant-eliminate the if false block early on, we'll get the wrong answer. I think the easiest answer is to simply ignore such blocks. They're rare, and ignoring them won't impact correctness. I'm not sure whether that works for @dr2chase's case, though.

[mdempsky]

That code's not valid: you can't goto into a block.

[josharian]

Oh right. That's C. :) Hurrah! Yes, early validation of labels/gotos sounds good, then. If we introduce bad labels/gotos in order/walk, that's our problem.

[dr2chase]

Early validation is better. I thought it was beyond the scope of my change, and also risked running into the front-end cleanup.

[ALTree]

For reference, I just hit mdempsky's caveat about labels while fuzzing the compiler.

After CL 38601 (cmd/compile: don't export dead code in inlineable fuctions) the following code does not compile any more:

package a

func F() {
l1:
	if false {
		goto l1
	}
}

package main

import "a"

func main() {
	a.F()
}

says:

# main
./0.go:6:5: label l1·1 defined and not used

[josharian]

CL 38773 covers some of this. It punts when labels or gotos are present, but in a way that shouldn't break anything, just generate less-optimized code. There is a known issue around handling checking for terminating statements that I'm unsure how best to handle. Suggestions welcome.

@ALTree any chance you could run your gosmith setup with that CL patched in for a bit? It seems very effective at finding related issues.

[gopherbot]

CL https://golang.org/cl/38773 mentions this issue.

[ALTree]

@josharian sure, will do.