We have completely separate paths to generate code to compare (=, !=) small structs/arrays and large structs/arrays. The small ones get inlined and happen in walk.go. The large ones get converted to a function call and happen in alg.go. (The small ones also get a function call generated, for use by maps.)

These separate code paths were fine when they they were fairly simple. However, I recently put some work into generating better eq alg routines (CLs 230203-230210). The inline comparisons could use some of the same optimizations, particularly better condition ordering.

And if we pulled both the code generation for small structs/arrays and the decision point for inlining into a re-usable function, we could do an even better job of generating code. Currently, the alg generation routines must treat structs as opaque. If we could break them apart into pieces, the way we (will soon) handle strings, we could profitably re-order their conditions as well. This would also help with #38494.

The proposal here is to do refactor out a unified code generation routine for comparing arrays and structs, much like CL 230204 and CL 230206 do for strings and interfaces, although more complicated. Then unify the implementation with geneq in alg.go. Then use that implementation recursively to generate better code.

This is probably accessible for someone with a bit of experience with the compiler, and some patience, so marking help wanted. I have no concrete plans to work on it at the moment.