cmd/compile: move tighten after lower

[josharian]

The tighten pass is currently scheduled before lower, "to avoid splitting naturally paired instructions such as CMP/SET". Doing tighten later benefits from the removal of values enabled by lowering and lowered CSE. Empirically, moving tighten just before phiTighten generates slightly better code: fewer bytes of instructions on average, and as far I have checked, a pareto improvement on stack use.

Moving tighten after lower will allow us to do this TODO in the code:

			for _, a := range v.Args {
				switch a.Op {
				case OpConst8, OpConst16, OpConst32, OpConst64, OpAddr:
					// Probably foldable into v, don't count as an argument needing a register.
					// TODO: move tighten to a machine-dependent phase and use v.rematerializeable()?

(And as a consequence, probably remove phiTighten, or at least merge it into tighten.)

If we notice problematic split pairs of instructions, like CMP/SET, we can teach tighten explicitly to leave them alone.

cc @randall77 @cherrymui @dr2chase

[gopherbot]

Change https://golang.org/cl/55236 mentions this issue: runtime: split declaration and assignment in mapassign

[randall77]

Sounds ok to me.
Normally we don't move 2-input values. But we have an exception where we do move 2-input boolean values, assuming they will become flags-generators and we want to move flag generators up to uses. If we tighten after lower, we can use flags-type instead of boolean-type to drive that decision.

[randall77]

Another example where this would help:

type T struct {
	a int
	b *int
}
func f(p *T) {
	p.b = nil
}

The write in f requires a write barrier. So there are two blocks that care about the address written, the write-barrier-on block and the write-barrier-off block.

The write-barrier-on block must compute the address to write to, which boils down to the following instruction:

	0x0028 00040 (tmp1.go:9)	LEAQ	8(CX), DI

The write-barrier-off block doesn't compute the address explicitly, instead it folds that computation into the store itself:

	0x0030 00048 (tmp1.go:9)	MOVQ	$0, 8(CX)

So ideally we should put the LEAQ in just the write-barrier-on block.

Unfortunately, tighten happens before lowering, and at that time the address computation is not folded into the store:

b1:
    v8 = OffPtr <**int> [8] v5
    ...
    If v12 -> b2 b3 (unlikely)
b2:
    v13 = WB <mem> {runtime.gcWriteBarrier} v8 v6 v1
b3:
    v14 = Store <mem> {*int} v8 v6 v1

So it looks like both the write-barrier-on block and the write-barrier-off block use v8. So v8 is left in the parent block instead of moving it to the write-barrier-on block. Only after lowering can we see that v8 won't be used in the write-barrier-off block.

[randall77]

That last example is #19853.

[gopherbot]

Change https://golang.org/cl/95995 mentions this issue: cmd/compile: tighten after lowering