cmd/compile, cmd/link: drop support for IntSize != PtrSize

[mdempsky]

TL;DR: Do we anticipate ever supporting architectures with IntSize != PtrSize again? (Note: This is different from supporting PtrSize != RegSize architectures like amd64p32.)

The Go spec allows int and pointers to be independently sized, and for Go 1.0, amd64 had 64-bit pointers but 32-bit ints. However, since Go 1.1, all supported architectures have had identically sized ints and pointers.

There's still vestigial code within the toolchain to support IntSize != PtrSize architectures, but it's not always used correctly. For example, ssa/gen/dec.rules and gc.(*ssafn).SplitSlice both calculate the cap field's offset as 2*Widthptr, when it should be Widthptr+Widthint. ld.textsectionmap assumes IntSize==PtrSize by using IntSize to populate uintptr fields.

I'm inclined to remove all the Int-named variables and just use the Ptr-named ones everywhere. As precedence, runtime/internal/sys only has PtrSize and RegSize, and go/types.StdSizes only has WordSize (with the same meaning as PtrSize).

[gopherbot]

CL https://golang.org/cl/40506 mentions this issue.

[rsc]

We made the distinction because we were trying to allow 32-bit int on 64-bit systems. But the region of memory addressable with a slice, and in particular a []byte, is limited by the size of int, which is why we raised it on 64-bit systems. I can't see going back on that in the current implementations. (The alternative was to introduce things like size_t, which we decided explicitly against.)

It seems OK to me to assume that sizeof(int) = sizeof(unsafe.Pointer) in the gc toolchain, but I'd like to hear from @randall77, @griesemer, and @ianlancetaylor too.

[randall77]

I'm all for removing the distinction. I could see cases where it would matter, like if we had decided that amd64p32 had 64-bit ints. But I don't see anything like that happening in our future.

[rsc]

Checked with @griesemer about this - in favor too - and he confirmed that go/types allows alternate implementations to override StdSizes by implementing the Sizes interface, so that it would still support alternate implementations that don't make this assumption. As long as this is limited to the gc toolchain, SGTM.

[ianlancetaylor]

I'm OK with this. We need a type to hold the size of the largest object that can be allocated, and that type is int (and we implicitly agree that no object can be larger than half of memory). We obviously need a pointer type.

On some processors, the pointer type is larger than a single register, so pointers are relatively expensive. On such a processor one could consider doing most arithmetic computations in a type smaller than the pointer size. But we would still need a type to hold the size of the largest object, and that type is int, so in effect we would have to use multiple registers to hold an int value. So for this case we can reasonably assume that int and pointer types are the same size.

On other processors a pointer register can hold more bits than can be used in memory. In fact, this is true on amd64. On such a processor it's pretty much always acceptable to waste a few bits for a pointer register to make it as large as an integer register. The interesting cases here are special purpose embedded processors with wide integer registers and small amounts of addressable memory. On such a processor one could imagine making int small. But that is OK, and it's unlikely that Go will be used on such a processor anyhow.

So I can't see a plausible case where making ints and pointers the same size would fail.

(If you want to think about weird processors I think a bigger problem area would be processors where memory is not byte addressable.)

[rsc]

Accepted by general agreement.

[gopherbot]

CL https://golang.org/cl/41398 mentions this issue.