This may be a decent starter issue for someone wanting to work on the compiler.

I'm not sure what this has to do with the compiler? It seems to be purely a runtime optimization - the linked CL doesn't touch cmd/compile at all.

Look for staticbytes in cmd/compile/internal/gc.

Right. But now that we have staticuint64s in the runtime, we can use it in the compiler.

For part one, grep the compiler for staticbytes and use staticuint64s instead. (The offset math will need to change a bit; see Keith's linked CL comment.) Then delete runtime.staticbytes.

For part two, in places where we only optimize byte-sized things, we can probably now optimize constant larger-int-sized things. The sites will be the same sites encountered in part one.

There are actually two more remaining uses of runtime.staticbytes, in src/runtime/string.go, for generating 1-character strings.

Thanks! Those could also be converted, using similar arithmetic.

Change https://golang.org/cl/221957 mentions this issue: cmd/compile: use staticuint64s instead of staticbytes

I've sent a CL implementing the first part of the compiler change. I'll do the other two follow-ups later.

Change https://golang.org/cl/221979 mentions this issue: runtime: use staticuint64s instead of staticbytes for 1-length strings

I was trying to do the small int constant part, but by the time walkexpr runs, the OLITERAL has been replaced with an ONAME node for a temporary:

before walk smallintiface
.   RETURN l(26) tc(1)
.   RETURN-list
.   .   CONVIFACE l(26) esc(h) tc(1) implicit(true) INTER-@0
.   .   .   NAME-codegen..stmp_3 l(26) x(0) class(PEXTERN) tc(1) used int

I can't figure out how to recover the value of the constant from that ONAME.

You’ll probably need to make a companion change to order.go at the same time. I’m AFK for a little while. If that isn’t enough of a hint, let me know and I’ll expand on it when I am at a real keyboard.

I tried narrowing the condition in the OCONVIFACE case of (*Order).expr as follows:

// Don't use a temporary for integer constants that fit in a byte; walk will replace
// them with pointers into runtime.staticuint64s.
if _, needsaddr := convFuncName(n.Left.Type, n.Type); (needsaddr || isStaticCompositeLiteral(n.Left)) && !(n.Left.CanInt64() && n.Left.Int64() >= 0 && n.Left.Int64() < 256) {

That almost works, but I get a couple of test failures, which seem directly relevant to this code:

# go run run.go -- writebarrier.go

Unmatched Errors:
writebarrier.go:288: write barrier

FAIL	writebarrier.go	0.092s
# go run run.go -- fixedbugs/issue31782.go
exit status 1
panic: interface conversion: interface {} is nil, not int

goroutine 1 [running]:
main.main()
	/Users/dpinela/dev/golang-dev/go/test/fixedbugs/issue31782.go:23 +0x78
exit status 2

FAIL	fixedbugs/issue31782.go	0.308s

I've had a look at the code in order.go and sinit.go that handles composite literals, but I'm having a hard time following what's going on, so I'm stuck.

Please post your changes in a CL so I can take a look. Thanks.

I’m still AFK, and due to coronavirus school closures, it is unclear when I will next have meaningful laptop time. But I will look as best as I can, next opportunity I get.

I wonder—have you checked what code we generate right now for this case? I wonder whether we have enough existing optimizations at tip (probably not 1.14) to already optimally handle the case of a small constant int. (There’s an entirely separate question of handling an int that is non-constant but whose unsigned equivalent provably fits in one byte. That we definitely don’t handle well now. But I don’t think that that is what you were looking at, either.)

Change https://golang.org/cl/223358 mentions this issue: cmd/compile: use staticuint64s to optimize interface conversion of small integer constants (WIP)

Currently (both 1.14 and tip) we generate a static global with the constant's value and use a pointer to that, like we do for string literals:

"".X STEXT nosplit size=25 args=0x10 locals=0x0
	0x0000 00000 (smallintiface.go:3)	TEXT	"".X(SB), NOSPLIT|ABIInternal, $0-16
	0x0000 00000 (smallintiface.go:3)	PCDATA	$0, $-2
	0x0000 00000 (smallintiface.go:3)	PCDATA	$1, $-2
	0x0000 00000 (smallintiface.go:3)	FUNCDATA	$0, gclocals·568470801006e5c0dc3947ea998fe279(SB)
	0x0000 00000 (smallintiface.go:3)	FUNCDATA	$1, gclocals·69c1753bd5f81501d95132d08af04464(SB)
	0x0000 00000 (smallintiface.go:3)	FUNCDATA	$2, gclocals·9fb7f0986f647f17cb53dda1484e0f7a(SB)
	0x0000 00000 (smallintiface.go:4)	PCDATA	$0, $1
	0x0000 00000 (smallintiface.go:4)	PCDATA	$1, $1
	0x0000 00000 (smallintiface.go:4)	LEAQ	type.int(SB), AX
	0x0007 00007 (smallintiface.go:4)	PCDATA	$0, $0
	0x0007 00007 (smallintiface.go:4)	MOVQ	AX, "".~r0+8(SP)
	0x000c 00012 (smallintiface.go:4)	PCDATA	$0, $1
	0x000c 00012 (smallintiface.go:4)	LEAQ	""..stmp_0(SB), AX
	0x0013 00019 (smallintiface.go:4)	PCDATA	$0, $0
	0x0013 00019 (smallintiface.go:4)	MOVQ	AX, "".~r0+16(SP)
	0x0018 00024 (smallintiface.go:4)	RET
[...]
""..stmp_0 SRODATA size=8
	0x0000 01 00 00 00 00 00 00 00                          ........

This is optimal in execution time, but not in binary size: pointing into staticuint64s would allow us to elide these globals, saving 8 bytes each in the common case of int constants on 64-bit architectures.

Moving to Backlog milestone.

Hi, Is this case an example of how to use it?

I'm working on reviving https://golang.org/cl/223358 as an intro to working on the compiler; so far I've found a few interesting things.

The issue31782.go failure is due to the fact that the CL implemented this conversion by leaving OLITERALs in the tree after order. However, walkCompLit calls isStaticCompositeLiteral, which treats OLITERAL as something that can be statically represented, which skips anylit, and convert never gets run on the struct literal as the intent is that nothing has to be converted. The OLITERALs then get miscompiled. I've "solved" this by performing the interface conversion (a subset of convert) early in order. But, I'm not sure that this is a good idea (as order doesn't do this normally). I've also found that walkCompLit is never called with a struct literal that contains an OLITERAL (if a struct fails, it's for other reasons; maybe this used to not be true before the big ir refactoring), so maybe the fix is to disallow OLITERAL there and move this code back to being split between order and convert.

The writebarrier.go issue is actually preexisting; it turns out that ssa apparently doesn't recognize offsets off of global static variables to be accesses that don't need a write barrier. Ever since the original optimization (bool/bytes) was introduced, the following code has had write barriers:

func foo() []interface{} {
    return []interface{}{
        true,   // ERROR "write barrier"
        int8(3) // ERROR "write barrier"
    }
}

Both values are converted to interfaces that contain staticuint64s+8 and similar, which get a write barrier. The CL revealed this because one of the writebarrier.go tests used 7, which is small enough to be staticuint64'd. No existing test verified that small values didn't have write barriers during interface conversions.

I'm not really sure how to solve that one; I asked @mdempsky about this and it seems like ssa would need to change to understand offsets into globals, which seems like a more impactful change. (But, I'm looking into it! 🙂)

I think I've been able to address all of the shortcomings (including the SSA bit), and plan to send my CL stack for review when the tree opens (after dev.typeparams is merged, since recent generic dictionary stuff has modified interface conversion a bit, so I've rebased it there).

Change https://golang.org/cl/342131 mentions this issue: cmd/compile: use staticuint64s for small constants

Change https://golang.org/cl/342129 mentions this issue: cmd/compile: don't emit write barriers for offsets of global addresses

Change https://golang.org/cl/342130 mentions this issue: cmd/compile: treat more address patterns as global