Found this bug while investigating avoiding to create algs for array types that are only used as backing array for slices.
It seems this is the reason our initial attempts at introducing that optimisation in https://go-review.googlesource.com/c/go/+/151497 failed with test errors.
Arrays marked noalg are created by the compiler to hold keys and values
to initialize map literals. The ssa backend creates a pointer type for the
array type when creating an OpAddr while processing the loop that
initializes the map from the arrays. The pointer type does not inherit
the noalg property but points to the noalg array type.
This leads to strange problems were the same values of a type dont compare equal anymore if created through reflect:
This is an unfortunate issue, and it should be fixed. But I think fixing it will be too invasive for Go 1.17.
As mentioned on CL 333030, I think the right fix here is to teach the linker to realize alg and noalg type descriptors can be deduplicated, but to prefer the alg variants when present. There's no need for alg and noalg types to have different descriptors; noalg types only exist as a space optimization to avoid creating the equality and hash functions for generated types that we know will never need those. And we can save even more space by getting rid of the redundant noalg variants when they're not needed.
(I'm sure there's some trickiness with dynamic linking here too. If we don't already, maybe we should just turn off noalg for dynamic linking. I imagine there are / will be similar issues there, and I think we have less control over symbol definition priority in the OS's dynamic linker.)