Skip to content
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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: merge TPTR32 and TPTR64 into TPTR? #15032

Closed
mdempsky opened this issue Mar 30, 2016 · 2 comments
Closed

cmd/compile: merge TPTR32 and TPTR64 into TPTR? #15032

mdempsky opened this issue Mar 30, 2016 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone
Unplanned

Comments

@mdempsky
Copy link
Contributor

I don't think there's any need for separate TPTR32 and TPTR64 types. Within a single package compilation, pointers are always Widthptr wide. Most of the code in the compiler either handles TPTR32 and TPTR64 identically, or only expects to see Tptr.

The only notable except appears to be in instruction selection, where there are cases like:

    case OADDR_ | gc.TPTR32:
            a = x86.ALEAL

    case OADDR_ | gc.TPTR64:
            a = x86.ALEAQ

But if we change the switch statement to use Simsimtype instead of Simtype, we can rewrite the cases to match on TUINT32/TUINT64 instead.
@josharian
Copy link
Contributor

SGTM, FWIW. Instruction selection probably may as well use Simsimtype anyway. And if that doesn't work, we can always check Widthptr inside a single Tptr case. However, before doing this, I'd say we should route as many TPTR32/TPTR64 checks through methods (IsPtr) and add a dynamic width test there. Just because the compiler should be indifferent doesn't mean it is. Every bit of code we clean up (named types, refactoring, field encapsulation) yields bugs, and I'd rather discover those bugs in a way that gives us nice stack traces.

@josharian josharian mentioned this issue Apr 3, 2016
Closed
@bradfitz bradfitz added this to the Unplanned milestone Apr 7, 2016
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@mdempsky
Copy link
Contributor Author

mdempsky commented Sep 7, 2023

This was done in 62e5215.

@mdempsky mdempsky closed this as completed Sep 7, 2023
@golang golang locked and limited conversation to collaborators Sep 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@bradfitz @mdempsky @josharian @gopherbot