@rsc

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.

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.)

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.

Change https://go.dev/cl/531997 mentions this issue: cmp: optimize Compare

It is done for #61725

Technically this issue isn't done, but since people can now call strings.Compare, close enough.