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.

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: merge TPTR32 and TPTR64 into TPTR? #15032

mdempsky opened this issue Mar 30, 2016 · 1 comment

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

mdempsky opened this issue Mar 30, 2016 · 1 comment


Copy link

@mdempsky mdempsky commented Mar 30, 2016

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.

Copy link

@josharian josharian commented Mar 31, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants