cmd/compile: optimize map[T]bool set for the same code performance as map[T]struct{} set

[qiulaidongfeng]

See CL 541218 , map[T]bool set has the same function as map[T]struct{} set, and the standard library also has the use of map[T]bool set, but map[T]bool set has more memory allocation and worse performance, which is evidence to support compiler optimization of map[T]bool set.

[qiulaidongfeng]

@gopherbot, please remove label Proposal.

[mpx]

map[T]bool provides 3 states: missing, present-true, present-false.
map[T]struct{} only provides: missing, present

Hence they aren't equivalent and map[T]struct{} can't be used as a general replacement.

It might be possible to analyse non-exported code to prove that only the missing and present-true states are needed an the apply an optimisation. I'm not convinced it's worth it.

I suspect code will generally improve when Go provides a common Set[T] type - if it's more convenient than map[T]bool it is more likely to be used when it matters.

[mknyszek]

Right, map[T]bool can contain boolean values that have nothing to do with map presence. The compiler would have to pattern-match and validate that all uses of the map conform to the following pattern:

x := make(map[T]bool)
...
x[t] = true
...
present := x[t]

I think that's difficult to do in general, though perhaps feasible within a package. It seems like an awfully specific thing to pattern-match for, though. A generic Set wrapper seems like possibly a better path forward here. (See #47331.)

Closing this issue for now, but perhaps someone from @golang/compiler wants to chime in.