Skip to content

Unboxed values / storage classes in backend #799

Open
@sorear

Description

@sorear

I would like to be able to write code using Word64 or floats without having to deal with constant boxing. This requires some coarse grained tracking of types (I am not proposing anything anywhere near the complexity of ghc core) so that values can be in appropriate registers. wordLang's view of the situation:

  • word which is interpreted by the GC as a smi or tagged pointer
  • native length word which is uninterpreted by the GC
  • floating point value stored in a floating point register (we may want both single and double)

Potentially:

  • we might want to allow real_addresses to live across calls, which requires special GC handling
  • this space reserved for target-specific storage classes e.g. vectors

This system should more or less work from flatLang to stackLang, but some thought needs to go into the type system integration. We could introduce a new family of unboxed types a la GHC, prevent type variables from being instantiated with unboxed types, allow unboxed types in datatype declarations and require all boxing and unboxing to be done explicitly using cons and pattern matching; or we could try to identify monomorphic types used in monomorphic contexts and unbox automatically somewhere near the front of the pipeline (at some risk of pathological behavior). GHC found it useful to introduce "unboxed tuples" to allow return value optimizations in a functional IR with single return values; I haven't thought very hard about whether we would need something similar.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions