Opened 6 years ago

Last modified 17 months ago

#5369 new bug

Reinstate VECTORISE pragmas with expressions as right-hand sides

Reported by: simonpj Owned by: chak
Priority: normal Milestone:
Component: Data Parallel Haskell Version: 7.0.4
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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.


*** 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
        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

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.

Change History (12)

comment:1 Changed 6 years ago by chak

Owner: set to chak

We agreed to handle this problem in two stages:

  1. For the moment, the pragmas will be restricted to be of the form {-# VECTORISE f = g #-}, where g is an identifier. Then, we need no type inference for the right-hand side of the pragma.
  2. Once the vectoriser got to a point, where we can call Vectorise.Type.vectType from the type checker, we will reinstate the more general form of the pragma again in a more robust form (where the type checker generates a suitable wrapper.)

comment:2 Changed 6 years ago by chak

I did the first stage:

commit ae6161ec6f2466ca2d04f098f350ce06090003b1
Author: Manuel M T Chakravarty <>
Date:   Sat Aug 20 23:08:10 2011 +1000

   Until the type checker can use vectorised signatures, we restrict the RHS of VECTORISE pragmas to be a single identifier only.

   - This removes the need to be careful about the order of dictionaries during type inference. A property that is too fragile to try to maintain in the type checker.

comment:3 Changed 6 years ago by igloo

Milestone: 7.4.1

comment:4 Changed 6 years ago by chak

@igloo The remaining work is not affecting users, but is just a convenience for us (the implementors). I'd suggest to set the milestone to 7.6.1.

comment:5 Changed 6 years ago by chak

Summary: Vectoriser depends in too-fragile a way on the type constraint solverReinstate VECTORISE pragmas with expressions as right-hand sides

comment:6 Changed 6 years ago by chak

Component: CompilerData Parallel Haskell

comment:7 Changed 6 years ago by igloo


comment:8 Changed 5 years ago by igloo


comment:9 Changed 3 years ago by thoughtpolice


Moving to 7.10.1.

comment:10 Changed 2 years ago by thoughtpolice


Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:11 Changed 21 months ago by thoughtpolice


Milestone renamed

comment:12 Changed 17 months ago by bgamari

Milestone: 8.0.1

Moving DPH tickets out to _|_ as the project is more or less stagnant.

Note: See TracTickets for help on using tickets.