x/crypto/sha3: re-introduce s390x assembly

[FiloSottile]

The current s390x assembly hooks into the package in such a way that it disables devirtualization, and by extension inlining and successful escape analysis for every architecture.

Specifically, current functions look like

func New256() hash.Hash {
	if h := new256Asm(); h != nil {
		return h
	}
	return &state{rate: 136, outputLen: 32, dsbyte: 0x06}
}

making the return type conditional, which doesn't work with devirtualization.

https://go.dev/cl/544816 disables the assembly (without removing it, to make re-enabling it easier and to preserve the git history), so that https://go.dev/cl/544817 can make the necessary changes so that the sha3 APIs can be used with zero allocations. (See the new TestAllocations.)

We plan to submit CL 544816 on January 8th, after the next x/crypto release is tagged (meaning the change will show up in @latest at the beginning of February). @golang/s390x maintainers are welcome to reintroduce it afterwards, or to chain a CL after CL 544817 to be submitted at the same time.

[mauri870]

I'll chain in a CL enabling the s390x assembly, thanks.

Edit CL 554435

[gopherbot]

Change https://go.dev/cl/554435 mentions this issue: sha3: reenable s390x assembly

[mauri870]

Any plans to submit said CLs @FiloSottile?

[FiloSottile]

They are waiting for review, ping @rolandshoemaker.

(They also somehow make Apple Silicon performance worse, and I didn't have time to look into why yet, but it's not necessarily a blocker.)