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

Closed
mdempsky opened this Issue Apr 13, 2017 · 7 comments

Comments

Projects
None yet
5 participants
@mdempsky
Member

mdempsky commented Apr 13, 2017

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 gopherbot added this to the Proposal milestone Apr 13, 2017

@gopherbot gopherbot added the Proposal label Apr 13, 2017

@gopherbot

This comment has been minimized.

Show comment
Hide comment

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

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Apr 17, 2017

Contributor

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.

Contributor

rsc commented Apr 17, 2017

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.

@rsc rsc changed the title from proposal: cmd: drop support for IntSize != PtrSize to proposal: cmd/compile, cmd/link: drop support for IntSize != PtrSize Apr 17, 2017

@randall77

This comment has been minimized.

Show comment
Hide comment
@randall77

randall77 Apr 17, 2017

Contributor

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.

Contributor

randall77 commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Apr 17, 2017

Contributor

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.

Contributor

rsc commented Apr 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Apr 17, 2017

Contributor

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.)

Contributor

ianlancetaylor commented Apr 17, 2017

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 rsc changed the title from proposal: cmd/compile, cmd/link: drop support for IntSize != PtrSize to cmd/compile, cmd/link: drop support for IntSize != PtrSize Apr 20, 2017

@rsc rsc modified the milestones: Go1.9, Proposal Apr 20, 2017

@rsc

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Apr 20, 2017

Contributor

Accepted by general agreement.

Contributor

rsc commented Apr 20, 2017

Accepted by general agreement.

@gopherbot

This comment has been minimized.

Show comment
Hide comment

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

gopherbot pushed a commit that referenced this issue Apr 21, 2017

cmd/compile: remove most uses of duintxx
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>

@gopherbot gopherbot closed this in c87520c Apr 22, 2017

gopherbot pushed a commit that referenced this issue Apr 23, 2017

cmd/link: cleanup after IntSize->PtrSize conversion
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>

gopherbot pushed a commit that referenced this issue Apr 23, 2017

cmd/compile: cleanup after IntSize->PtrSize conversion
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>

@golang golang locked and limited conversation to collaborators Apr 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.