cmd/compile: Optimize three-way string comparisons

[ashi009]

As shown in strings.Compare's source code, three-way string comparisons can be optimized.

A few use cases are:

• sorted slice merging
• sorted slice intersection
• sorted slice intersection detection

For the last use case my benchmark showed a over 10% improvement by using bytes.Compare instaed of strings.Compare.

[agnivade]

@rsc

[randall77]

Currently we break string comparison ops into runtime calls during walk.
If we delayed that lowering until later in SSA, we could maybe detect the use of both s1 == s2 and s1 < s2 and use a single call in that case.

[josharian]

This would be another possible use for an rtcall SSA pass: #24926

But it’d be better indeed to leave these unlowered until much later. Which would require making it reasonable to manipulate and insert calls in SSA. Which is yet another reason to move parameter and result handling into ssa ops instead of SP writes and reads. (I’m pretty sure I’ve written this paragraph a dozen times. I should just go do it.)

[dsymonds]

This would also be nice so that strings.Compare can have that rsc comment removed entirely, since it can be clearer to use it instead of the builtin operators in some cases, such as building a higher level comparison func.

type key struct {
  f1, f2, f3 string
}

func (k key) Compare(o key) int {
  if c := strings.Compare(k.f1, o.f1); c != 0 {
    return c
  }
  if c := strings.Compare(k.f2, o.f2); c != 0 {
    return c
  }
  if c := strings.Compare(k.f3, o.f3); c != 0 {
    return c
  }
  return 0
}

I mean, I could always implement my own strCompare helper func if strings.Compare didn't exist, but this optimisation would merely apply to that instead of strings.Compare.