Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/compile, cmd/link: drop support for IntSize != PtrSize #19954
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
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
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).
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.)
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.
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
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
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
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.)
The only remaining uses of duintxx are in the implementation of duintNN. I hope to inline those once I figure out why CL 40864 is broken. Note that some uses of duintxx with width Widthint were converted into duintptr. I did that, since #19954 is officially going to move forward. Passes toolstash-check. Change-Id: Id25253b711ea589d0199b51be9a3c18ca1af59ce Reviewed-on: https://go-review.googlesource.com/41398 Run-TryBot: Josh Bleecher Snyder <firstname.lastname@example.org> Reviewed-by: Matthew Dempsky <email@example.com>
Also, replace "PtrSize == 4 && Arch != amd64p32" with "RegSize == 4". Passes toolstash-check -all. Updates #19954. Change-Id: I79b2ee9324f4fa53e34c9271d837ea288b5d7829 Reviewed-on: https://go-review.googlesource.com/41491 Run-TryBot: Matthew Dempsky <firstname.lastname@example.org> Reviewed-by: Brad Fitzpatrick <email@example.com>