#5369: Vectoriser depends in too-fragile a way on the type constraint solver
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.4
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
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`.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5369>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
