Skip to content

Reinstate VECTORISE pragmas with expressions as right-hand sides

The current vectoriser depends in a very fragile way on the order in which the constraint solver generates constraints. This ticket is just to track this known problem.

Manifestation:

*** Vectorisation error ***
    Type mismatch in vectorisation pragma for Data.Array.Parallel.unzipP
        Expected type forall a_a1SF b_a1SG.
                      (Data.Array.Parallel.PArray.PRepr.PA a_a1SF,
                       Data.Array.Parallel.PArray.PRepr.PA b_a1SG) =>
                      Data.Array.Parallel.PArray.Base.PArray (a_a1SF, b_a1SG)
                      Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
                                                                a_a1SF,
                                                              Data.Array.Parallel.PArray.Base.PArray
                                                                b_a1SG)
        Inferred type forall a_a21g b_a21h.
                      (Data.Array.Parallel.PArray.PRepr.PA b_a21h,
                       Data.Array.Parallel.PArray.PRepr.PA a_a21g) =>
                      Data.Array.Parallel.PArray.Base.PArray (a_a21g, b_a21h)
                      Data.Array.Parallel.Lifted.Closure.:-> (Data.Array.Parallel.PArray.Base.PArray
                                                                a_a21g,
                                                              Data.Array.Parallel.PArray.Base.PArray
                                                                b_a21h)

Reason: the compilation of VECTORISE pragmas depends on the order of constraints in an inferred type. This isn't trivial to fix. As Manuel writes, the problem here is that we do not know what wrapper w we need *until* the vectoriser runs. Why is that? Given

  f :: ty
  f = e
  {-# VECTORISE f = e_v #-}

where the type *inferred* for e_v is ty_v, we need to mediate between ty_v and V[[ty]]. (Here V[[ty]] is the transformation that maps a regular type to a vectorised type.)

It is V[[ty]] that we cannot determine until the vectoriser runs. If we could compute V[ty]] in the type checker, we could use it together with ty_v to compute a wrapper w as you propose.

Alas, given the current implementation of V[[..]] in the vectoriser (it is implemented in Vectorise.Type.vectType), we cannot call it in the type checker, because it runs in the VM monad, which is a variant of the 'DsM' monad. In particular, 'VM' uses some tables of names of types and functions defined in the DPH library that are not available during type checking. (I briefly considered duplicating the code for vectType as a stop gap measure in TcM, but that didn't seem to be so easy.)

I believe that the Right Thing to do is to change the 'VM' monad and the implementation of vectType, so that it is more flexible and can be called from TcM. The changes that I am making at the moment (i.e., cutting down these tables of magic, built-in things) will make it easier to improve vectType.

Trac metadata
Trac field Value
Version 7.0.4
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Edited by Manuel M T Chakravarty
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information