cmd/compile: (dev.typeparams) assembly generated for a simple generic function is massive

[OneOfOne]

This isn't really a bug, just maybe something to keep in mind for later optimizations?

Feel free to close

//go:noinline
func AddN(a, b int) int { return a + b }

//go:noinline
func AddT[T interface{ ~int }](a, b T) T { return a + b }

Generates (go tool compile -S -G=3 main.go) :

"".AddN STEXT nosplit size=4 args=0x10 locals=0x0 funcid=0x0
	0x0000 00000 (main.go:12)	TEXT	"".AddN(SB), NOSPLIT|ABIInternal, $0-16
	0x0000 00000 (main.go:12)	FUNCDATA	$0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (main.go:12)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0000 00000 (main.go:12)	FUNCDATA	$5, "".AddN.arginfo1(SB)
	0x0000 00000 (main.go:13)	ADDQ	BX, AX
	0x0003 00003 (main.go:13)	RET
	0x0000 48 01 d8 c3                                      H...
""..inst.AddT[int] STEXT dupok size=98 args=0x18 locals=0x18 funcid=0x0
	0x0000 00000 (main.go:17)	TEXT	""..inst.AddT[int](SB), DUPOK|ABIInternal, $24-24
	0x0000 00000 (main.go:17)	CMPQ	SP, 16(R14)
	0x0004 00004 (main.go:17)	PCDATA	$0, $-2
	0x0004 00004 (main.go:17)	JLS	61
	0x0006 00006 (main.go:17)	PCDATA	$0, $-1
	0x0006 00006 (main.go:17)	SUBQ	$24, SP
	0x000a 00010 (main.go:17)	MOVQ	BP, 16(SP)
	0x000f 00015 (main.go:17)	LEAQ	16(SP), BP
	0x0014 00020 (main.go:17)	FUNCDATA	$0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0014 00020 (main.go:17)	FUNCDATA	$1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
	0x0014 00020 (main.go:17)	FUNCDATA	$5, ""..inst.AddT[int].arginfo1(SB)
	0x0014 00020 (main.go:17)	MOVQ	(AX), DX
	0x0017 00023 (main.go:17)	LEAQ	type.int(SB), SI
	0x001e 00030 (main.go:17)	NOP
	0x0020 00032 (main.go:17)	CMPQ	DX, SI
	0x0023 00035 (main.go:17)	JNE	51
	0x0025 00037 (main.go:18)	LEAQ	(BX)(CX*1), AX
	0x0029 00041 (main.go:18)	MOVQ	16(SP), BP
	0x002e 00046 (main.go:18)	ADDQ	$24, SP
	0x0032 00050 (main.go:18)	RET
	0x0033 00051 (main.go:17)	XORL	AX, AX
	0x0035 00053 (main.go:17)	XORL	BX, BX
	0x0037 00055 (main.go:17)	PCDATA	$1, $0
	0x0037 00055 (main.go:17)	CALL	runtime.gopanic(SB)
	0x003c 00060 (main.go:17)	XCHGL	AX, AX
	0x003d 00061 (main.go:17)	NOP
	0x003d 00061 (main.go:17)	PCDATA	$1, $-1
	0x003d 00061 (main.go:17)	PCDATA	$0, $-2
	0x003d 00061 (main.go:17)	MOVQ	AX, 8(SP)
	0x0042 00066 (main.go:17)	MOVQ	BX, 16(SP)
	0x0047 00071 (main.go:17)	MOVQ	CX, 24(SP)
	0x004c 00076 (main.go:17)	CALL	runtime.morestack_noctxt(SB)
	0x0051 00081 (main.go:17)	MOVQ	8(SP), AX
	0x0056 00086 (main.go:17)	MOVQ	16(SP), BX
	0x005b 00091 (main.go:17)	MOVQ	24(SP), CX
	0x0060 00096 (main.go:17)	PCDATA	$0, $-1
	0x0060 00096 (main.go:17)	JMP	0

[ianlancetaylor]

CC @randall77 @danscales

The dev.typeparams work is undergoing very active change, and it is much much too early to start reporting bugs against it. Contributions are welcome but filing bugs now will just be a distraction. I've CC'ed the relevant people but I'm going to close this issue. Thanks.

[OneOfOne]

@ianlancetaylor this isn't a bug, it was more of a something to look at before the branch commits to using dictionary types.

[ianlancetaylor]

Thanks, but we prefer to use the issue tracker for bug reports and proposals. If you want to discuss the approach being taken on the dev.typeparams branch, I recommend using golang-dev. But it is much much too early to draw any conclusions at all based on the code being generated.

[randall77]

In particular, half those instructions are just for debugging - they will disappear in the real implementation.
(0x14-0x25 and 0x33-0x3d).