Always unbox single-constructor datatypes #142
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Always unbox single-constructor datatypes even when the constructor argument is itself unboxed. For instance, consider the datatype declaration
Such types appear in the code generated by ML Yacc and ML Lex. We can also support more general cases such as
Here all the types (
ValEnv
,Env
,StrEnv
) can be represented unboxed even when maps (Ident.Map.map
andStrId.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.