If these optimizations sound reasonable i can work on this for 1.9/1.10 after i have my current projects for 1.9 are submitted.

Both could be handled calculated together in a combined uint64divmod runtime call

SGTM. We even already have this, although it's called dodiv at the moment.

In case y is constant the compiler could optimize the calculation to not require a div and not need a runtime call

The compiler should already do this. Worth double-checking, though.

It's probably also work taking a brief look at the code that the compiler generates for vlrt.go. It was tuned for the old backend.

about 2. I checked before and after the issue creation :)

The compiler does not simplify a div with 64bit operands on 32bit:

var x uint64

func main() {
	y := x / 10
	print(y)
}

uses a "CALL runtime.uint64div(SB)"

:) I see.

Both seem worth fixing, then.

Independently, I wonder whether it's worth adding an int32 code path, where we do all the work with int32s instead of int64s, for values that fit in 32 bits (which is probably almost all of them in practice). Might even be cheaper on 64 bit machines. Probably worth a benchmarking experiment.