cmd/compile: avoid repeated write barrier checks

[CAFxX]

(I quickly went through the open write barrier issues and couldn't find something covering this, so here goes. Sorry if I missed it.)

While investigating something completely unrelated (I'm on 1.17 on darwin/amd64), I noticed that we coalesce writes behind a single write barrier check, but we don't do so consistently:

In the loop on the left, we check whether the write barrier is enabled 4 times, even though once would suffice. I could understand redoing the check if there were function calls or otherwise a significant amount of code between two wb checks, but that's not the case in this specific instance.

In this instance, I would have expected instead at most one write barrier check per loop iteration and the whole jump-threaded wb-enabled version pushed away to a cold section of the function. Given the tiny amount of code in the common parts, and the elimination of the compare and jumps due to jump-threading, it is even possible that total code size would decrease.

Just for completeness, the go code goes something like this:

	// var wg1, wg2 sync.WaitGroup
	// var p = runtime.GOMAXPROCS(0)
	for i := 0; i < p; i++ {
		wg1.Add(1)
		wg2.Add(1)
		t := time.NewTicker(d)
		go func() {
            // lots of stuff
        }()
    }

(Another thing that is visible in that graph is that sometimes both predecessors of a basic block end with an unconditional jump: with better ordering one of the two jumps should not be required)

[randall77]

I think the back-and-forth is due the fact that when we write a composite value, we share the scalar-writing parts and then branch for the pointer-writing parts.
You're right, we could duplicate some code to remove some checks. We'd need some sort of cost model for doing that.