(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)