Changes between Version 29 and Version 30 of DataParallel/ClosureConversion/ClassLess


Ignore:
Timestamp:
Apr 30, 2007 10:31:44 AM (7 years ago)
Author:
chak
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DataParallel/ClosureConversion/ClassLess

    v29 v30  
    124124 
    125125 
    126 === Converting class and instances === 
     126=== Converting classes and instances === 
    127127 
    128128We don't alter class and instance declarations in any way.  However, the dictionary type constructors and dfuns are processed in the same way as other data types and value bindings, respectively; i.e., they get a `StatusCC` field and we generate converted versions and conversion constructors as usual. 
     
    132132---- 
    133133 
    134 === Converting instance declarations === 
    135  
    136 If we encounter an instance declaration for `C tau` during conversion, there are two alternatives: we have a conversion for `C` or not: 
    137  * if we do not have a conversion, we generate an instance (and hence dfun) for `C tau^`, where `tau^` is the closure converted `tau`; 
    138  * if we have a conversion, we generate an instance for `C_CC tau^`. 
    139 In any case, we add a field `is_CC :: StatusCC Instance` to `InstEnv.Instance` that contains the additionally generated instance.  And in both cases, we should be able to derive the required code for the dfun from the definition of `C tau`.  We also make sure that the `dfun`'s `idCC` field (see below) is set to that of the converted dfun. 
    140134 
    141135=== Converting type terms === 
     
    185179The only remaining problem is that a type parameter to a function may itself be a type parameter got from a calling function; so similar to classes, we need to pass conversion functions with every type parameter.  So, maybe we want to stick `fr` and `to` into a class after all and requires that all functions used in converted contexts have the appropriate contexts in their signatures. 
    186180 
    187 === Issues, aka rl's complaints === 
    188  
    189 ==== Unboxed types ==== 
    190  
    191 Consider 
    192 {{{ 
    193 data Int = Int# I# 
    194 }}} 
    195 The declaration has no arrow, so we set its `tyConCC` field to `ConvCC Int` (given that we know that all unboxed types can be used unaltered).  Moreover, {{{Int# :: I# -> Int}}} has no converted form as is has an unboxed argument. 
    196  
    197 ==== Non-converted versus unchanged type declarations ==== 
    198  
    199 '''This issue has now been addressed.''' 
    200  
    201 Many type declarations will not be changed by conversion, as they do not contain any arrows.  Hence, it is more economic to avoid generating a `_CC` version of these declarations.  I initially thought that we can ignore this for a moment, because it is only an optimisation.  However, consider 
    202 {{{ 
    203 data T = MkT Int 
    204 data S = MkS (Int -> Int) 
    205 }}} 
    206 As we don't convert `Int`, we cannot convert `T` and `S`, which is a shame as their conversion is simple and (in the vectorisation case may affect performance dramatically).  As a matter of fact, if we identify declarations that need not be converted, then we would mark `Int` and `T` as such and can convert `S` easily. 
    207  
    208 ==== FC Coercions ==== 
    209  
    210 '''This issue has now been addressed.''' 
    211  
    212 Closure conversion happens on Core, which means that constructors, such as `MkT` of 
    213 {{{ 
    214 -- unconverted 
    215 newtype T a = MkT (a -> a) 
    216 }}} 
    217 in a definition 
    218 {{{ 
    219 -- converted 
    220 foo :: (a -> a) -> T a 
    221 foo f = MkT f 
    222 }}} 
    223 have vanished, leaving only a coercion.  As `T` is not converted, we need to notice that we need to generate `MkT (fr f)`.  So, we need to spot the conversion representing `MkT`. 
    224  
    225 Generally, we need a story about treating coercions during conversion. 
    226  
    227 ==== Function type constructor ==== 
    228  
    229 It is clear how to treat types involving subtypes of the form `a -> b`.  It is less clear how to deal with partial applications of `(->)`.  Consider 
    230 {{{ 
    231 -- unconverted 
    232 data T f = T (Int -> Int) (f Int Int) 
    233 }}} 
    234 used as `T (->)` in converted code.  What is `convert (T (->))`? 
    235  
    236 ==== Classes ==== 
    237  
    238 '''This issue has now been addressed''' 
    239  
    240 It might be sufficient to never convert class declarations as a whole, but only their representation types. 
     181=== TODO === 
    241182 
    242183==== Original functions ====