cmd/compile: call generated size-specialized malloc functions directly

This change creates calls to size-specialized malloc functions instead
of calls to newObject when we know the size of the allocation at
compilation time. Most of it is a matter of calling the newObject
function (which will create calls to the size-specialized functions)
rather then the newObjectNonSpecialized function (which won't). In the
newHeapaddr, small, non-pointer case, we'll create a non specialized
newObject and transform that into the appropriate size-specialized
function when we produce the mallocgc in flushPendingHeapAllocations.

We have to update some of the rewrites in generic.rules to also apply to
the size-specialized functions when they apply to newObject.

The messiest thing is we have to adjust the offset we use to save the
memory profiler stack, because the depth of the call to profilealloc is
two frames fewer in the size-specialized malloc functions compared to
when newObject calls mallocgc. A bunch of tests have been adjusted to
account for that.

Change-Id: I6a6a6964c9037fb6719e392c4a498ed700b617d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/707856
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>

1 files changed, 1 insertions, 1 deletions

diff --git a/test/codegen/strings.go b/test/codegen/strings.go
index 498c3d398f..0b3ca7016f 100644
--- a/test/codegen/strings.go
+++ b/test/codegen/strings.go
@@ -23,7 +23,7 @@ func CountBytes(s []byte) int {
 
 func ToByteSlice() []byte { // Issue #24698
 	// amd64:`LEAQ\ttype:\[3\]uint8`
-	// amd64:`CALL\truntime\.newobject`
+	// amd64:`CALL\truntime\.mallocTiny3`
 	// amd64:-`.*runtime.stringtoslicebyte`
 	return []byte("foo")
 }