cmd/compile: combine BSWAP on amd64

[josharian]

package p

import "encoding/binary"

func f(b []byte, x *[8]byte) {
	_ = b[8]
	t := binary.BigEndian.Uint64(x[:])
	binary.BigEndian.PutUint64(b, t)
}

This should compile down to two MOVQs on amd64, one to load from x and one to write to b.

Instead, it contains two successive BSWAP instructions. We should eliminate those. As a bonus, we should eliminate any BSWAPS separated only by bitwise operations. For example:

package p

import "encoding/binary"

func f(b []byte, x *[8]byte) {
	_ = b[8]
	t := binary.BigEndian.Uint64(x[:])
	t = ^t
	binary.BigEndian.PutUint64(b, t)
}

(In addition to unary ^, there's binary &, |, and ^. Maybe some others?)

One advantage to this kind of optimization is that it reduces the important of whether the endianness selected in the code matches the endianness of the architecture the code is being executed on.

Related: #41663

cc @agarciamontoro

[agarciamontoro]

@josharian, I'd like to work on this one, too, as I guess it's quite similar to #41663

By the way, should this one be added to go1.17 too?

[josharian]

Great! Let me know if you have any questions.

[agarciamontoro]

I am working on this, finally, and the first part of the issue is easily solvable with a rule such as:

(BSWAPQ (BSWAPQ p)) => p

@josharian, do we need to check that the inner BSWAPQ is used only once? Something like this:

(BSWAPQ a:(BSWAPQ p))
    && a.Uses == 1
    && clobber(a) =>
    p

I think I understand what the Uses field is for and what the clobber function does, but I'm not sure I got it 100%.

Thanks!

EDIT: All tests pass with both versions.

[josharian]

No need to check uses or to clobber; your simple version suffices. BSWAP works on a regular value (held in a register), not directly on memory.

Feel free to stop at the double BSWAP elimination—eliminating the bitwise operations is, as I said, a bonus. :)

Are there other architectures to apply it to? Worth doing BSWAPL?

Note the 1.17 freeze has begun. Feel free to mail your changes, but they won't go in until the 1.18 cycle.

[agarciamontoro]

No need to check uses or to clobber; your simple version suffices. BSWAP works on a regular value (held in a register), not directly on memory.

Cool, thanks for the info!

Feel free to stop at the double BSWAP elimination—eliminating the bitwise operations is, as I said, a bonus. :)

I actually have the unary ^ kind of solved, too. I was wondering what the other cases are. You talk about some binary bitwise operations, but between what values? Should I test that with another array argument similar to x?

Are there other architectures to apply it to?

That's my next step, I wanted to take a look!

Worth doing BSWAPL?

Yup, I was actually thinking about doing something a bit more general, like

(BSWAP(Q|L) (BSWAP(Q|L) p)) => p

Note the 1.17 freeze has begun. Feel free to mail your changes, but they won't go in until the 1.18 cycle.

I konw, thanks for the heads-up!

[josharian]

You talk about some binary bitwise operations, but between what values? Should I test that with another array argument similar to x?

Yes, exactly.

#31586 will probably be useful context for this.

[agarciamontoro]

I'm sending a CL covering only the double swap case. I added rules for both amd64 and arm64. I am not familiar at all with s390x nor with ppc64le, but I think the double swap was not happening there. The test does cover s390x (this should be reviewed with even more care, though), but I had no clue on what to do with ppc64le. We can discuss in the CL itself, if that works for you.

Regarding the other cases (the unary and binary bitwise operations): should we open a new issue for them? I can probably start taking a deeper look next Friday.

[gopherbot]

Change https://golang.org/cl/320073 mentions this issue: cmd/compile: eliminate successive swaps

[agarciamontoro]

@josharian, should we add this to the 1.18 milestone? I'm planning on finishing the work here this or next week.

[josharian]

@agarciamontoro this won't block the 1.18 milestone, so there's no need, but thanks for checking in. (And for working on it.)