runtime: investigate a hybrid memory clearing strategy based on prove results

[jake-ciolek]

In some cases, it might be better/faster to have a hybrid memory clear where from prove we know that a clear will be at least X bytes long.

We could use a static clear and then handle the unknown-sized remainder (either via a call to memclrNoHeapPointers or some inlined clear for the remainder). This could improve performance or allow more optimizations to fire due to the static clear part enabling things like DSE.

[randall77]

In what situations would we know that the size is >X but not constant?

[jake-ciolek]

I dumped it from prove and didn't get to confirm whether this ends up being compiled to a call to memclrNoHeapPointers or not, but:

go/src/cmd/link/internal/ld/data.go

Line 2275 in cf93b25

data = append(data, 0)

It seems that if prove was able to have a min limit on the len then we could use it to setup the static clear.

[randall77]

I don't follow how that snippet of code is relevant to this issue.

[jake-ciolek]

A simple example could be something like:

func myfunc(clear bool, size int, arr [32]int8) []int8 {
    slice := arr[:]

    for i := 0 ; i < size ; i++ {
        slice = append(slice, int8(i))
    }

    if clear && size & 1 == 0 {
      // We know that this len has to be at least 32 so we could
      // create a static 32 byte clear and handle the rest dynamically
      for x := range slice {
          slice[x] = 0
      }
    }

    return slice
}

[randall77]

This seems like an exceedingly rare situation. I'd want to see a situation where this actually triggers before we spend time on it.

Since we have to call into the runtime anyway, it also seems like a really small win.

[jake-ciolek]

On a related note, maybe we could use PGO to find clears where one clear size dominates. If they are almost always x we could inline the most common clear and then have check if size == x (otherwise call memclrnoheappointers).