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

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@haskell.org] On Behalf Of Ömer
| Sinan Agacan
| Sent: 25 August 2016 11:46
| To: ghc-devs

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
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@haskell.org] On Behalf Of Ömer | Sinan Agacan | Sent: 25 August 2016 11:46 | To: ghc-devs
| 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@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%7cb1571fb2c4e24941998308d3 | ccd519bb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ilDdLBFdfvzY1g6Z | iuHyY6W%2bOIq2Y69f5YTgmpqwRO8%3d

* 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@gmail.com]
Sent: 25 August 2016 17:46
To: Simon Peyton Jones
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
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@haskell.org] On Behalf Of | Ömer Sinan Agacan | Sent: 25 August 2016 11:46 | To: ghc-devs
| 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@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
participants (2)
-
Simon Peyton Jones
-
Ömer Sinan Ağacan