Can we mark DataCon ptrs only in allocation sites and not generate entry code?

Simon Peyton Jones simonpj at microsoft.com
Thu Aug 25 21:52:14 UTC 2016


* Not every pointer to a datacon is tagged.  The pointer 
  might point to a thunk originally (one of many such pointers;
  then the thunk is updated to a datacon, but the pointer 
  doesn't know that.

* The tagging at dynamic allocation sites is optional.
  In   f x xs = let y = x:xs in g y
  we don't HAVE to tag y.  We could pass it untagged to g,
  which would evaluate it.  But since we know it is a cons,
  it's silly NOT to tag it, because then g can avoid the eval.

* In contrast, setting the tag in the entry code for the constructor
  is NOT optional, because it's part of the return protocol
  for returning from a constructor.

Simon

-----Original Message-----
From: Ömer Sinan Ağacan [mailto:omeragacan at gmail.com] 
Sent: 25 August 2016 17:46
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Can we mark DataCon ptrs only in allocation sites and not generate entry code?

> StgCmmCon.hs:240 reads
>              ; return (mkRhsInit dflags reg lf_info hp_plus_n) }
>
> what's that got to do with pointer tagging?

If I understand correctly, mkRhsInit returns a tagged pointer:

    mkRhsInit :: DynFlags -> LocalReg -> LambdaFormInfo -> CmmExpr -> CmmAGraph
    mkRhsInit dflags reg lf_info expr
      = mkAssign (CmmLocal reg) (addDynTag dflags expr (lfDynTag dflags lf_info))

> But also we clearly must do so in the entry code for a data 
> constructor

Why? It's not clear to me. If every pointer to a constructor is tagged then maybe we don't need to enter constructors at all.

2016-08-25 15:41 GMT+00:00 Simon Peyton Jones <simonpj at microsoft.com>:
> StgCmmCon.hs:240 reads
>              ; return (mkRhsInit dflags reg lf_info hp_plus_n) }
>
> what's that got to do with pointer tagging?
>
>
> But yes we need to do it in both places.  Consider
>
> f x xs = let y = x:xs
>          in g y
>
> We should tag y before passing it to g.  That's the StgCmmCon case.
>
>
> But also we clearly must do so in the entry code for a data 
> constructor
>
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of 
> | Ömer  Sinan Agacan
> |  Sent: 25 August 2016 11:46
> |  To: ghc-devs <ghc-devs at haskell.org>
> |  Subject: Can we mark DataCon ptrs only in allocation sites and not  
> | generate entry code?
> |
> |  As far as I can see in the native code compiler we mark DataCon  
> | pointers in two places:
> |
> |  1. In allocation sites (StgCmmCon.hs:240)  2. In DataCon entry code 
> | (StgCmm.hs:244)
> |
> |  I was wondering why we can't get away with just doing (1). Can 
> | anyone  give me  an example where an allocation doesn't return a 
> | tagged pointer and we  need to  tag it in entry code? If every 
> | allocation returns a tagged pointer,  then why do  we need (2) ?
> |
> |  Thanks
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  
> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail
> | .h
> |  askell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
> |  
> | devs&data=01%7c01%7csimonpj%40microsoft.com%7cb1571fb2c4e24941998308
> | d3  
> | ccd519bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ilDdLBFdfvzY1g
> | 6Z
> |  iuHyY6W%2bOIq2Y69f5YTgmpqwRO8%3d


More information about the ghc-devs mailing list