headers
Ranjit Jhala | 18 Mar 2013 19:06
Gravatar

scope invariants in core

Hi all,

I have been manipulating CoreExpr to convert it to A-Normal Form.
Mostly, things have been working fine, but I hit an error this
morning of the form:

    lq_anf__d11u is out of scope

where lq_anf__d11u is a binder I have introduced in the transformed expression

    Data.ByteString.Internal.c_strlen =
   (\ (ds_d11l :: GHC.Ptr.Ptr Foreign.C.Types.CChar) ->
      case ds_d11l of lq_anf__d11t { GHC.Ptr.Ptr ds_d11n ->
      let {
        lq_anf__d11x
          :: GHC.Prim.State# GHC.Prim.RealWorld
             -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Word.Word32 #)
        [LclId]
        lq_anf__d11x =
          \ (ds_d11q :: GHC.Prim.State# GHC.Prim.RealWorld) ->
            case {__pkg_ccall main strlen GHC.Prim.Addr#
                         -> GHC.Prim.State# GHC.Prim.RealWorld
                         -> (# GHC.Prim.State# GHC.Prim.RealWorld,
GHC.Prim.Word# #)}
                   ds_d11n ds_d11q
            of lq_anf__d11u { __DEFAULT ->
            case lq_anf__d11u of lq_anf__d11v { (# ds_d11p, ds_d11o #) ->
            let {
              lq_anf__d11w :: GHC.Word.Word32
              [LclId]
(Continue reading)

Permalink | Reply |
headers
Simon Peyton-Jones | 18 Mar 2013 21:32
Picon
Favicon
Gravatar

RE: scope invariants in core

That does seem odd.

Use -dppr-debug so you can see the actual unique on each Id, just to make sure the print-name isn't different
from the underlying unique.

In an older version of GHC (before March 2012) variables could not be bound to unboxed tuples, so if your fork
is based on a sufficiently old version that might be a problem.

Aha.  Before the patch below, I see this code in Core Lint

commit 09987de4ece1fc634af6b2b37173b12ed46fdf3e
Author: Max Bolingbroke <batterseapower <at> hotmail.com>
Date:   Sun Mar 18 00:00:38 2012 +0000

    Support code generation for unboxed-tuple function arguments

    This is done by a 'unarisation' pre-pass at the STG level which
    translates away all (live) binders binding something of unboxed
    tuple type.

    This has the following knock-on effects:
      * The subkind hierarchy is vastly simplified (no UbxTupleKind or ArgKind)
      * Various relaxed type checks in typechecker, 'foreign import prim' etc
      * All case binders may be live at the Core level

|  -----Original Message-----
|  From: glasgow-haskell-users-bounces <at> haskell.org [mailto:glasgow-haskell-users-
|  bounces <at> haskell.org] On Behalf Of Ranjit Jhala
|  Sent: 18 March 2013 18:06
|  To: glasgow-haskell-users <at> haskell.org
(Continue reading)

Permalink | Reply |
headers
Simon Peyton-Jones | 18 Mar 2013 21:34
Picon
Favicon
Gravatar

RE: scope invariants in core

That does seem odd.

Use -dppr-debug so you can see the actual unique on each Id, just to make sure the print-name isn't different
from the underlying unique.

In an older version of GHC (before March 2012; patch below) variables could not be bound to unboxed tuples,
so if your fork is based on a sufficiently old version that might be a problem.

Aha.  Before the patch below, I see this code in Core Lint

     -- If the binder is an unboxed tuple type, don't put it in scope
     ; let scope = if (isUnboxedTupleType (idType var)) then 
                       pass_var 
                   else lintAndScopeId var

and indeed the patch below removes those lines.  So that's it.  You need to update. Whether you can do so for
just this one patch is more than I can say!

Simon

commit 09987de4ece1fc634af6b2b37173b12ed46fdf3e
Author: Max Bolingbroke <batterseapower <at> hotmail.com>
Date:   Sun Mar 18 00:00:38 2012 +0000

    Support code generation for unboxed-tuple function arguments

    This is done by a 'unarisation' pre-pass at the STG level which
    translates away all (live) binders binding something of unboxed
    tuple type.
(Continue reading)

Permalink | Reply |
headers
Ranjit Jhala | 18 Mar 2013 22:28
Gravatar

Re: scope invariants in core

Hi Simon -- Terrific, this seems to be the ticket...! Thanks a bunch! Ranjit.

On Mon, Mar 18, 2013 at 1:34 PM, Simon Peyton-Jones
<simonpj <at> microsoft.com> wrote:
> That does seem odd.
>
> Use -dppr-debug so you can see the actual unique on each Id, just to make sure the print-name isn't
different from the underlying unique.
>
> In an older version of GHC (before March 2012; patch below) variables could not be bound to unboxed tuples,
so if your fork is based on a sufficiently old version that might be a problem.
>
> Aha.  Before the patch below, I see this code in Core Lint
>
>      -- If the binder is an unboxed tuple type, don't put it in scope
>      ; let scope = if (isUnboxedTupleType (idType var)) then
>                        pass_var
>                    else lintAndScopeId var
>
> and indeed the patch below removes those lines.  So that's it.  You need to update. Whether you can do so for
just this one patch is more than I can say!
>
> Simon
>
> commit 09987de4ece1fc634af6b2b37173b12ed46fdf3e
> Author: Max Bolingbroke <batterseapower <at> hotmail.com>
> Date:   Sun Mar 18 00:00:38 2012 +0000
>
>     Support code generation for unboxed-tuple function arguments
>
(Continue reading)

Permalink | Reply |

Gmane