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

Always unbox single-constructor datatypes #142

Merged
merged 5 commits into from
Nov 4, 2023
Merged

Always unbox single-constructor datatypes #142

merged 5 commits into from
Nov 4, 2023

Conversation

melsman
Copy link
Owner

@melsman melsman commented Nov 3, 2023

Always unbox single-constructor datatypes even when the constructor argument is itself unboxed. For instance, consider the datatype declaration

datatype t = N of int

Such types appear in the code generated by ML Yacc and ML Lex. We can also support more general cases such as

datatype ValEnv = VALENV of Ident.Map.map
datatype Env = ENV of StrEnv * ValEnv  
         and StrEnv = STRENV of Env StrId.Map.map

Here all the types (ValEnv, Env, StrEnv) can be represented unboxed even when maps (Ident.Map.map and StrId.Map.map) are represented unboxed (e.g., patricia trees or association lists).

The decision about unboxing is done in src/Compiler/Lambda/CompileDec.sml. The major issue resolved here is for polymorphic equality elimination to generate proper code for comparing singular datatypes for equality. Previously, unnecessary branches were generated, which lead to code being generated for switch-constructs that would null out the least-significant bits in values carried by singular unboxed value constructors.

This PR partly resolves issue #99.

@melsman melsman self-assigned this Nov 3, 2023
@melsman melsman merged commit 1337844 into master Nov 4, 2023
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant