Changes between Version 34 and Version 35 of DataParallel/VectPragma


Ignore:
Timestamp:
Nov 24, 2011 4:09:56 AM (2 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/VectPragma

    v34 v35  
    8787== The VECTORISE SCALAR pragma for type constructors == 
    8888 
     89=== Without right-hand side === 
     90 
    8991For a type constructor `T`, the pragma 
    9092{{{ 
    9193{-# VECTORISE SCALAR type T #-} 
    9294}}} 
    93 indicates that the type is scalar; i.e., it has no embedded arrays and its constructors can *only* be used in scalar code.  Note that the type cannot be parameterised (as we would not be able to rule out that a type parameter is instantiated with an array type at a usage site.) 
     95indicates that the type is scalar; i.e., it has no embedded arrays and its constructors can '''only''' be used in scalar code.  Note that the type cannot be parameterised (as we would not be able to rule out that a type parameter is instantiated with an array type at a usage site.) 
    9496 
    9597Due to this pragma declaration, `T` that may be used in vectorised code, where `T` represents itself.  However, the representation of `T` is opaque in vectorised code. An example is the treatment of `Int`.  `Int`s can be used in vectorised code and remain unchanged by vectorisation.  However, the representation of `Int` by the `I#` data constructor wrapping an `Int#` is not exposed in vectorised code.  Instead, computations involving the representation need to be confined to scalar code. 
     
    99101NB: The crucial difference between `{-# VECTORISE SCALAR type T1 #-}` and `{-# VECTORISE type T2 #-}`, where `T2` embeds no parallel arrays, is that the *representation* (i.e., the constructors) of the former can only be used in scalar code. However, neither the representation of `T1` nor `T2` does get vectorised — so, both types are suitable for code that does not get vectorised due to vectorisation avoidance. 
    100102 
     103=== With right-hand side === 
     104 
     105For a type constructor `T`, the pragma 
     106{{{ 
     107{-# VECTORISE SCALAR type T = T' #-} 
     108}}} 
     109directs the vectoriser to replace `T` by `T'` in vectorised code, but its constructors can '''only''' be used in scalar code. 
     110 
     111The type constructor `T` must be in scope, but it may be imported.  The `PData` and `PRepr` instances for `T` need to be manually defined.  
     112 
     113An example is the handling of `[::]`, which the vectoriser maps to `PArray`, but it never looks at the implementation of `[::]`. 
     114 
    101115'''TODO:''' 
    102  * '''Maybe''' `{-# VECTORISE SCALAR type T = T' #-}` can be useful for, e.g., mapping `(->)` to `(:->)`??? 
    103116 * For type constructors identified with this pragma, can we generate an `instance` of the `Scalar` type class automatically (instead of relying on it being in the library)? 
     117 * Maybe `VECTORISE ABSTRACT` would be a better name as it doesn't guarantee that the type constructor can be used in scalar code that doesn't need to be vectorised. It just means that the data constructors can '''only''' be used in scalar code — i.e., the vectoriser treats it as an abstract type. 
    104118 
    105119== The VECTORISE pragma for type classes ==