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

Use representation types for expressions and shapes #455

Merged
merged 41 commits into from
Jun 5, 2020

Conversation

ivogabe
Copy link
Contributor

@ivogabe ivogabe commented Mar 25, 2020

Description

Before this PR, the types of expressions would refer to surface types. This PR changes that: internally the type now regards the representation type, similar to what I did previously on Acc in #449. A quick summary of the changes:

  • The type argument of data types like Exp, PreOpenExp from AST.hs regards representation types.
  • In Smart.hs, we introduced SmartExp to capture the recursion. Its type argument regards representation types. To hide this change to the user, we wrap this in newtype Exp t = Exp (SmartExp (EltRepr t)).
  • Tuples of expressions are now constructed using Pair and Nil.
  • Each expression variable in the AST now regards a scalar type. Tuple types must thus be stored in multiple variables.
  • SIMD Vectors (Vec n t) are now more explicit in the AST. Creating vectors or extracting data from them is achieved by converting the vector from/to a tuple. This is done using VecPack and VecUnpack.
  • Added pattern synonyms to expose this to the user: V2_, V3_, V4_, V8_ and V16_
  • Removed Pattern.hs
  • Instead of multiple instances Elt (Vec n t) for different single types, we have now have only one instance. We use type class VecElt to denote which single types can be stored in a Vec.
  • Complex can be used on all types instead of only floating point numbers.

Motivation and context

This change should make the internals of Accelerate easier, as it is easier to reason in terms of representation types, and in terms of variables of a scalar type.

How has this been tested?

The tests are all passing :)

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@ivogabe
Copy link
Contributor Author

ivogabe commented Mar 26, 2020

GHC 8.8 doesn't believe anymore that the type family GArrayData is injective. I'll remove the injectivity annotation and add manual type applications.

type Tup8 a b c d e f g h = (((((((((), a), b), c), d), e), f), g), h)
type Tup9 a b c d e f g h i = ((((((((((), a), b), c), d), e), f), g), h), i)
type Tup16 a b c d e f g h
i j k l m n o p = ((((((((((((((((((), a), b), c), d), e), f), g), h), i), j), k), l), m), n), o), p))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there is a redundant pair of outer parentheses here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, good catch!

tmcdonell added a commit to tmcdonell/accelerate that referenced this pull request Jun 5, 2020
@tmcdonell tmcdonell merged commit 8e78c22 into AccelerateHS:master Jun 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants