You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
But if we change the switch statement to use Simsimtype instead of Simtype, we can rewrite the cases to match on TUINT32/TUINT64 instead.
The text was updated successfully, but these errors were encountered: