-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile, cmd/link: drop support for IntSize != PtrSize #19954
Comments
CL https://golang.org/cl/40506 mentions this issue. |
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. |
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. |
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.) |
Accepted by general agreement. |
CL https://golang.org/cl/41398 mentions this issue. |
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 <josharian@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Passes toolstash-check -all. Updates #19954. Change-Id: Ic162306eed105912491bf1df47e32c32653f824c Reviewed-on: https://go-review.googlesource.com/41490 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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 <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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-bitint
s. However, since Go 1.1, all supported architectures have had identically sizedint
s 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 as2*Widthptr
, when it should beWidthptr+Widthint
. ld.textsectionmap assumes IntSize==PtrSize by using IntSize to populateuintptr
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).
The text was updated successfully, but these errors were encountered: