Code generation/SRT question

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Code generation/SRT question

Ömer Sinan Ağacan
Hi Simon,

In Cmm if I have a recursive group of functions f and g, and I'm using f's
closure as the SRT for this group, should f's entry block's info table have
f_closure as its SRT?

In Cmm syntax

     f_entry() {
             { info_tbls: [...
                           (c1vn,
                            label: ...
                            rep: ...
                            srt: ??????]
               stack_info: ...
             }
         {offset
           c1vn:
             ...
         }
     }

Here should I have `f_closure` in the srt field?

I'd expect yes, but looking at the current SRT code, in
CmmBuildInfoTables.updInfoSRTs, we have this:

  (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of

    Nothing ->
      -- if we don't add SRT entries to this closure, then we
      -- want to set the srt field in its info table as usual
      (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])

    Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
      (info_tbl { cit_rep = new_rep }, res)
      where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]

Here we only update SRT field of the block if we're not adding SRT entries to
the function's closure, so in the example above, because we're using the
function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
be updated.

Am I missing anything?

Thanks,

Ömer
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Code generation/SRT question

Simon Marlow-7
There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?

The use of a closure as an SRT is really quite a nice optimisation actually.

Cheers
Simon

On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:
Hi Simon,

In Cmm if I have a recursive group of functions f and g, and I'm using f's
closure as the SRT for this group, should f's entry block's info table have
f_closure as its SRT?

In Cmm syntax

     f_entry() {
             { info_tbls: [...
                           (c1vn,
                            label: ...
                            rep: ...
                            srt: ??????]
               stack_info: ...
             }
         {offset
           c1vn:
             ...
         }
     }

Here should I have `f_closure` in the srt field?

I'd expect yes, but looking at the current SRT code, in
CmmBuildInfoTables.updInfoSRTs, we have this:

  (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of

    Nothing ->
      -- if we don't add SRT entries to this closure, then we
      -- want to set the srt field in its info table as usual
      (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])

    Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
      (info_tbl { cit_rep = new_rep }, res)
      where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]

Here we only update SRT field of the block if we're not adding SRT entries to
the function's closure, so in the example above, because we're using the
function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
be updated.

Am I missing anything?

Thanks,

Ömer

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Code generation/SRT question

GHC - devs mailing list

Omer,

 

I think I’m not understanding all the details, but I have a clear “big picture”.   Simon can correct me if I’m wrong.

 

·        The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT.

·        The SRT for an info table identifies the static top level closures that the code for that info table mentions.   (In principle the garbage collector could parse the code! But it’s easier to find these references if they in a dedicated table alongside the code.)

·        A top level closure is a CAF if it is born updatable.

·        A top level closure is CAFFY if it is a CAF, or mentions another CAFFY closure.

·        An entry in the SRT can point

o   To a top-level updatable closure. This may now point into the dynamic heap, and is what we want to keep alive.  If the closure hasn’t been updated, we should keep alive anything its SRT points to.

o   Directly to another SRT (or info table?) for a CAFFY top-level closure, which is a bit faster if we know the thing is non-updatable.

·        If a function f calls a top-level function g, and g is CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF) directly to its SRT.

·        If f is top level, and calls itself, there is no need to include a pointer to f’s closure in f’s own SRT.

I think this last point is the one you are asking, but I’m not certain.

All this should be written down somewhere, and perhaps is.  But where?

Simon

 

From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
Sent: 06 January 2020 08:17
To: Ömer Sinan Ağacan <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: Code generation/SRT question

 

There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?

 

The use of a closure as an SRT is really quite a nice optimisation actually.

 

Cheers

Simon

 

On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:

Hi Simon,

In Cmm if I have a recursive group of functions f and g, and I'm using f's
closure as the SRT for this group, should f's entry block's info table have
f_closure as its SRT?

In Cmm syntax

     f_entry() {
             { info_tbls: [...
                           (c1vn,
                            label: ...
                            rep: ...
                            srt: ??????]
               stack_info: ...
             }
         {offset
           c1vn:
             ...
         }
     }

Here should I have `f_closure` in the srt field?

I'd expect yes, but looking at the current SRT code, in
CmmBuildInfoTables.updInfoSRTs, we have this:

  (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of

    Nothing ->
      -- if we don't add SRT entries to this closure, then we
      -- want to set the srt field in its info table as usual
      (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])

    Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
      (info_tbl { cit_rep = new_rep }, res)
      where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]

Here we only update SRT field of the block if we're not adding SRT entries to
the function's closure, so in the example above, because we're using the
function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
be updated.

Am I missing anything?

Thanks,

Ömer


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Code generation/SRT question

Simon Marlow-7
We have:

Maybe we need links to these from other places?

Omer's question is referring specifically to the [FUN] optimisation described in the Note.

Cheers
Simon

On Mon, 6 Jan 2020 at 17:50, Simon Peyton Jones <[hidden email]> wrote:

Omer,

 

I think I’m not understanding all the details, but I have a clear “big picture”.   Simon can correct me if I’m wrong.

 

·        The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT.

·        The SRT for an info table identifies the static top level closures that the code for that info table mentions.   (In principle the garbage collector could parse the code! But it’s easier to find these references if they in a dedicated table alongside the code.)

·        A top level closure is a CAF if it is born updatable.

·        A top level closure is CAFFY if it is a CAF, or mentions another CAFFY closure.

·        An entry in the SRT can point

o   To a top-level updatable closure. This may now point into the dynamic heap, and is what we want to keep alive.  If the closure hasn’t been updated, we should keep alive anything its SRT points to.

o   Directly to another SRT (or info table?) for a CAFFY top-level closure, which is a bit faster if we know the thing is non-updatable.

·        If a function f calls a top-level function g, and g is CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF) directly to its SRT.

·        If f is top level, and calls itself, there is no need to include a pointer to f’s closure in f’s own SRT.

I think this last point is the one you are asking, but I’m not certain.

All this should be written down somewhere, and perhaps is.  But where?

Simon

 

From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
Sent: 06 January 2020 08:17
To: Ömer Sinan Ağacan <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: Code generation/SRT question

 

There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?

 

The use of a closure as an SRT is really quite a nice optimisation actually.

 

Cheers

Simon

 

On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:

Hi Simon,

In Cmm if I have a recursive group of functions f and g, and I'm using f's
closure as the SRT for this group, should f's entry block's info table have
f_closure as its SRT?

In Cmm syntax

     f_entry() {
             { info_tbls: [...
                           (c1vn,
                            label: ...
                            rep: ...
                            srt: ??????]
               stack_info: ...
             }
         {offset
           c1vn:
             ...
         }
     }

Here should I have `f_closure` in the srt field?

I'd expect yes, but looking at the current SRT code, in
CmmBuildInfoTables.updInfoSRTs, we have this:

  (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of

    Nothing ->
      -- if we don't add SRT entries to this closure, then we
      -- want to set the srt field in its info table as usual
      (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])

    Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
      (info_tbl { cit_rep = new_rep }, res)
      where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]

Here we only update SRT field of the block if we're not adding SRT entries to
the function's closure, so in the example above, because we're using the
function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
be updated.

Am I missing anything?

Thanks,

Ömer


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Code generation/SRT question

GHC - devs mailing list

Aha, great.  Well at least [Note SRTs] should point back to the wiki page.

 

Omer's question is referring specifically to the [FUN] optimisation described in the Note.

Hmm.  So is he asking whether f’s SRT should have an entry for itself?  No, that’ would be silly!  It would not lead to any more CAFs being reachable.

 

Omer, maybe we are misunderstanding.   But if so, can you cast your question more precisely in terms of which lines of the wiki page or Note are you asking about?  And let’s make sure that the appropriate bit gets updated when you’ve nailed the answer

 

Simon

 

From: Simon Marlow <[hidden email]>
Sent: 06 January 2020 18:17
To: Simon Peyton Jones <[hidden email]>
Cc: Ömer Sinan Ağacan <[hidden email]>; ghc-devs <[hidden email]>
Subject: Re: Code generation/SRT question

 

We have:

 

Maybe we need links to these from other places?

 

Omer's question is referring specifically to the [FUN] optimisation described in the Note.

 

Cheers

Simon

 

On Mon, 6 Jan 2020 at 17:50, Simon Peyton Jones <[hidden email]> wrote:

Omer,

 

I think I’m not understanding all the details, but I have a clear “big picture”.   Simon can correct me if I’m wrong.

 

·        The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT.

·        The SRT for an info table identifies the static top level closures that the code for that info table mentions.   (In principle the garbage collector could parse the code! But it’s easier to find these references if they in a dedicated table alongside the code.)

·        A top level closure is a CAF if it is born updatable.

·        A top level closure is CAFFY if it is a CAF, or mentions another CAFFY closure.

·        An entry in the SRT can point

o   To a top-level updatable closure. This may now point into the dynamic heap, and is what we want to keep alive.  If the closure hasn’t been updated, we should keep alive anything its SRT points to.

o   Directly to another SRT (or info table?) for a CAFFY top-level closure, which is a bit faster if we know the thing is non-updatable.

·        If a function f calls a top-level function g, and g is CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF) directly to its SRT.

·        If f is top level, and calls itself, there is no need to include a pointer to f’s closure in f’s own SRT.

I think this last point is the one you are asking, but I’m not certain.

All this should be written down somewhere, and perhaps is.  But where?

Simon

 

From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
Sent: 06 January 2020 08:17
To: Ömer Sinan Ağacan <[hidden email]>
Cc: ghc-devs <[hidden email]>
Subject: Re: Code generation/SRT question

 

There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?

 

The use of a closure as an SRT is really quite a nice optimisation actually.

 

Cheers

Simon

 

On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:

Hi Simon,

In Cmm if I have a recursive group of functions f and g, and I'm using f's
closure as the SRT for this group, should f's entry block's info table have
f_closure as its SRT?

In Cmm syntax

     f_entry() {
             { info_tbls: [...
                           (c1vn,
                            label: ...
                            rep: ...
                            srt: ??????]
               stack_info: ...
             }
         {offset
           c1vn:
             ...
         }
     }

Here should I have `f_closure` in the srt field?

I'd expect yes, but looking at the current SRT code, in
CmmBuildInfoTables.updInfoSRTs, we have this:

  (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of

    Nothing ->
      -- if we don't add SRT entries to this closure, then we
      -- want to set the srt field in its info table as usual
      (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])

    Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
      (info_tbl { cit_rep = new_rep }, res)
      where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]

Here we only update SRT field of the block if we're not adding SRT entries to
the function's closure, so in the example above, because we're using the
function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
be updated.

Am I missing anything?

Thanks,

Ömer


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Code generation/SRT question

Ömer Sinan Ağacan
Hi all,

> There's no need to set the srt field of f_info if f_closure is the SRT, since
> any reference to f_info in the code will give rise to a reference to f_closure
> in the SRT corresponding to that code fragment. Does that make sense?

Makes sense, thanks.

> The use of a closure as an SRT is really quite a nice optimisation actually.

Agreed.

> · If f is top level, and calls itself, there is no need to include a pointer
> to f’s closure in f’s own SRT.
>
> I think this last point is the one you are asking, but I’m not certain.

Close, I'm asking whether we should include a pointer to f in f's SRT (when f is
recursive) when we're using f as the SRT (the [FUN] optimisation).

I'll document the code I quoted in my original email with this info.

Thanks,

Ömer

Simon Peyton Jones <[hidden email]>, 7 Oca 2020 Sal, 00:11
tarihinde şunu yazdı:

>
> Aha, great.  Well at least [Note SRTs] should point back to the wiki page.
>
>
>
> Omer's question is referring specifically to the [FUN] optimisation described in the Note.
>
> Hmm.  So is he asking whether f’s SRT should have an entry for itself?  No, that’ would be silly!  It would not lead to any more CAFs being reachable.
>
>
>
> Omer, maybe we are misunderstanding.   But if so, can you cast your question more precisely in terms of which lines of the wiki page or Note are you asking about?  And let’s make sure that the appropriate bit gets updated when you’ve nailed the answer
>
>
>
> Simon
>
>
>
> From: Simon Marlow <[hidden email]>
> Sent: 06 January 2020 18:17
> To: Simon Peyton Jones <[hidden email]>
> Cc: Ömer Sinan Ağacan <[hidden email]>; ghc-devs <[hidden email]>
> Subject: Re: Code generation/SRT question
>
>
>
> We have:
>
> * wiki: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts/storage/gc/cafs
>
> * a huge Note in CmmBuildInfoTables: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler%2Fcmm%2FCmmBuildInfoTables.hs#L42
>
>
>
> Maybe we need links to these from other places?
>
>
>
> Omer's question is referring specifically to the [FUN] optimisation described in the Note.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Mon, 6 Jan 2020 at 17:50, Simon Peyton Jones <[hidden email]> wrote:
>
> Omer,
>
>
>
> I think I’m not understanding all the details, but I have a clear “big picture”.   Simon can correct me if I’m wrong.
>
>
>
> ·        The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT.
>
> ·        The SRT for an info table identifies the static top level closures that the code for that info table mentions.   (In principle the garbage collector could parse the code! But it’s easier to find these references if they in a dedicated table alongside the code.)
>
> ·        A top level closure is a CAF if it is born updatable.
>
> ·        A top level closure is CAFFY if it is a CAF, or mentions another CAFFY closure.
>
> ·        An entry in the SRT can point
>
> o   To a top-level updatable closure. This may now point into the dynamic heap, and is what we want to keep alive.  If the closure hasn’t been updated, we should keep alive anything its SRT points to.
>
> o   Directly to another SRT (or info table?) for a CAFFY top-level closure, which is a bit faster if we know the thing is non-updatable.
>
> ·        If a function f calls a top-level function g, and g is CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF) directly to its SRT.
>
> ·        If f is top level, and calls itself, there is no need to include a pointer to f’s closure in f’s own SRT.
>
> I think this last point is the one you are asking, but I’m not certain.
>
> All this should be written down somewhere, and perhaps is.  But where?
>
> Simon
>
>
>
> From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
> Sent: 06 January 2020 08:17
> To: Ömer Sinan Ağacan <[hidden email]>
> Cc: ghc-devs <[hidden email]>
> Subject: Re: Code generation/SRT question
>
>
>
> There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?
>
>
>
> The use of a closure as an SRT is really quite a nice optimisation actually.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:
>
> Hi Simon,
>
> In Cmm if I have a recursive group of functions f and g, and I'm using f's
> closure as the SRT for this group, should f's entry block's info table have
> f_closure as its SRT?
>
> In Cmm syntax
>
>      f_entry() {
>              { info_tbls: [...
>                            (c1vn,
>                             label: ...
>                             rep: ...
>                             srt: ??????]
>                stack_info: ...
>              }
>          {offset
>            c1vn:
>              ...
>          }
>      }
>
> Here should I have `f_closure` in the srt field?
>
> I'd expect yes, but looking at the current SRT code, in
> CmmBuildInfoTables.updInfoSRTs, we have this:
>
>   (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of
>
>     Nothing ->
>       -- if we don't add SRT entries to this closure, then we
>       -- want to set the srt field in its info table as usual
>       (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])
>
>     Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
>       (info_tbl { cit_rep = new_rep }, res)
>       where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]
>
> Here we only update SRT field of the block if we're not adding SRT entries to
> the function's closure, so in the example above, because we're using the
> function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
> be updated.
>
> Am I missing anything?
>
> Thanks,
>
> Ömer
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Code generation/SRT question

GHC - devs mailing list
|  Close, I'm asking whether we should include a pointer to f in f's SRT
|  (when f is
|  recursive) when we're using f as the SRT (the [FUN] optimisation).

Definitely not.  Doing so would not change the set of reachable CAFs, would it?

Simon

|  -----Original Message-----
|  From: Ömer Sinan Ağacan <[hidden email]>
|  Sent: 07 January 2020 05:59
|  To: Simon Peyton Jones <[hidden email]>
|  Cc: Simon Marlow <[hidden email]>; ghc-devs <[hidden email]>
|  Subject: Re: Code generation/SRT question
|  
|  Hi all,
|  
|  > There's no need to set the srt field of f_info if f_closure is the
|  SRT, since
|  > any reference to f_info in the code will give rise to a reference to
|  f_closure
|  > in the SRT corresponding to that code fragment. Does that make
|  sense?
|  
|  Makes sense, thanks.
|  
|  > The use of a closure as an SRT is really quite a nice optimisation
|  actually.
|  
|  Agreed.
|  
|  > · If f is top level, and calls itself, there is no need to include a
|  pointer
|  > to f’s closure in f’s own SRT.
|  >
|  > I think this last point is the one you are asking, but I’m not
|  certain.
|  
|  Close, I'm asking whether we should include a pointer to f in f's SRT
|  (when f is
|  recursive) when we're using f as the SRT (the [FUN] optimisation).
|  
|  I'll document the code I quoted in my original email with this info.
|  
|  Thanks,
|  
|  Ömer
|  
|  Simon Peyton Jones <[hidden email]>, 7 Oca 2020 Sal, 00:11
|  tarihinde şunu yazdı:
|  >
|  > Aha, great.  Well at least [Note SRTs] should point back to the wiki
|  page.
|  >
|  >
|  >
|  > Omer's question is referring specifically to the [FUN] optimisation
|  described in the Note.
|  >
|  > Hmm.  So is he asking whether f’s SRT should have an entry for
|  itself?  No, that’ would be silly!  It would not lead to any more CAFs
|  being reachable.
|  >
|  >
|  >
|  > Omer, maybe we are misunderstanding.   But if so, can you cast your
|  question more precisely in terms of which lines of the wiki page or
|  Note are you asking about?  And let’s make sure that the appropriate
|  bit gets updated when you’ve nailed the answer
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > From: Simon Marlow <[hidden email]>
|  > Sent: 06 January 2020 18:17
|  > To: Simon Peyton Jones <[hidden email]>
|  > Cc: Ömer Sinan Ağacan <[hidden email]>; ghc-devs <ghc-
|  [hidden email]>
|  > Subject: Re: Code generation/SRT question
|  >
|  >
|  >
|  > We have:
|  >
|  > * wiki:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fcommentary%2Frts%2Fstorage%2Fgc%2
|  Fcafs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cba8ca780e8cb4803d53
|  008d79336b5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63713973549
|  8781862&amp;sdata=tz51aoG0hxYD8IMV0CTubLxuDnSO22pl9IU%2Bh6KxrGg%3D&amp
|  ;reserved=0
|  >
|  > * a huge Note in CmmBuildInfoTables:
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%252Fcmm%252FCmmB
|  uildInfoTables.hs%23L42&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb
|  a8ca780e8cb4803d53008d79336b5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1
|  %7C0%7C637139735498781862&amp;sdata=FymrjC9QgtuQM0AS0ZtV3yTec0hqFxYuKa
|  55XNqihNs%3D&amp;reserved=0
|  >
|  >
|  >
|  > Maybe we need links to these from other places?
|  >
|  >
|  >
|  > Omer's question is referring specifically to the [FUN] optimisation
|  described in the Note.
|  >
|  >
|  >
|  > Cheers
|  >
|  > Simon
|  >
|  >
|  >
|  > On Mon, 6 Jan 2020 at 17:50, Simon Peyton Jones
|  <[hidden email]> wrote:
|  >
|  > Omer,
|  >
|  >
|  >
|  > I think I’m not understanding all the details, but I have a clear
|  “big picture”.   Simon can correct me if I’m wrong.
|  >
|  >
|  >
|  > ·        The info table for any closure (top-level or otherwise) has
|  a (possibly empty) Static Reference Table, SRT.
|  >
|  > ·        The SRT for an info table identifies the static top level
|  closures that the code for that info table mentions.   (In principle
|  the garbage collector could parse the code! But it’s easier to find
|  these references if they in a dedicated table alongside the code.)
|  >
|  > ·        A top level closure is a CAF if it is born updatable.
|  >
|  > ·        A top level closure is CAFFY if it is a CAF, or mentions
|  another CAFFY closure.
|  >
|  > ·        An entry in the SRT can point
|  >
|  > o   To a top-level updatable closure. This may now point into the
|  dynamic heap, and is what we want to keep alive.  If the closure
|  hasn’t been updated, we should keep alive anything its SRT points to.
|  >
|  > o   Directly to another SRT (or info table?) for a CAFFY top-level
|  closure, which is a bit faster if we know the thing is non-updatable.
|  >
|  > ·        If a function f calls a top-level function g, and g is
|  CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF)
|  directly to its SRT.
|  >
|  > ·        If f is top level, and calls itself, there is no need to
|  include a pointer to f’s closure in f’s own SRT.
|  >
|  > I think this last point is the one you are asking, but I’m not
|  certain.
|  >
|  > All this should be written down somewhere, and perhaps is.  But
|  where?
|  >
|  > Simon
|  >
|  >
|  >
|  > From: ghc-devs <[hidden email]> On Behalf Of Simon
|  Marlow
|  > Sent: 06 January 2020 08:17
|  > To: Ömer Sinan Ağacan <[hidden email]>
|  > Cc: ghc-devs <[hidden email]>
|  > Subject: Re: Code generation/SRT question
|  >
|  >
|  >
|  > There's no need to set the srt field of f_info if f_closure is the
|  SRT, since any reference to f_info in the code will give rise to a
|  reference to f_closure in the SRT corresponding to that code fragment.
|  Does that make sense?
|  >
|  >
|  >
|  > The use of a closure as an SRT is really quite a nice optimisation
|  actually.
|  >
|  >
|  >
|  > Cheers
|  >
|  > Simon
|  >
|  >
|  >
|  > On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan
|  <[hidden email]> wrote:
|  >
|  > Hi Simon,
|  >
|  > In Cmm if I have a recursive group of functions f and g, and I'm
|  using f's
|  > closure as the SRT for this group, should f's entry block's info
|  table have
|  > f_closure as its SRT?
|  >
|  > In Cmm syntax
|  >
|  >      f_entry() {
|  >              { info_tbls: [...
|  >                            (c1vn,
|  >                             label: ...
|  >                             rep: ...
|  >                             srt: ??????]
|  >                stack_info: ...
|  >              }
|  >          {offset
|  >            c1vn:
|  >              ...
|  >          }
|  >      }
|  >
|  > Here should I have `f_closure` in the srt field?
|  >
|  > I'd expect yes, but looking at the current SRT code, in
|  > CmmBuildInfoTables.updInfoSRTs, we have this:
|  >
|  >   (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of
|  >
|  >     Nothing ->
|  >       -- if we don't add SRT entries to this closure, then we
|  >       -- want to set the srt field in its info table as usual
|  >       (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])
|  >
|  >     Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
|  >       (info_tbl { cit_rep = new_rep }, res)
|  >       where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]
|  >
|  > Here we only update SRT field of the block if we're not adding SRT
|  entries to
|  > the function's closure, so in the example above, because we're using
|  the
|  > function as SRT (and adding SRT entries to its closure) SRT field of
|  c1vn won't
|  > be updated.
|  >
|  > Am I missing anything?
|  >
|  > Thanks,
|  >
|  > Ömer
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Code generation/SRT question

Simon Marlow-7
In reply to this post by Ömer Sinan Ağacan

On Tue, 7 Jan 2020 at 05:59, Ömer Sinan Ağacan <[hidden email]> wrote:
Hi all,

> There's no need to set the srt field of f_info if f_closure is the SRT, since
> any reference to f_info in the code will give rise to a reference to f_closure
> in the SRT corresponding to that code fragment. Does that make sense?

Makes sense, thanks.

> The use of a closure as an SRT is really quite a nice optimisation actually.

Agreed.

> · If f is top level, and calls itself, there is no need to include a pointer
> to f’s closure in f’s own SRT.
>
> I think this last point is the one you are asking, but I’m not certain.

Close, I'm asking whether we should include a pointer to f in f's SRT (when f is
recursive) when we're using f as the SRT (the [FUN] optimisation).

I think your original question was slightly different, it was about f's info table:

> should f's entry block's info table have f_closure as its SRT?

anyway, the answer to both questions is "no."

Cheers
Simon

 
I'll document the code I quoted in my original email with this info.

Thanks,

Ömer

Simon Peyton Jones <[hidden email]>, 7 Oca 2020 Sal, 00:11
tarihinde şunu yazdı:
>
> Aha, great.  Well at least [Note SRTs] should point back to the wiki page.
>
>
>
> Omer's question is referring specifically to the [FUN] optimisation described in the Note.
>
> Hmm.  So is he asking whether f’s SRT should have an entry for itself?  No, that’ would be silly!  It would not lead to any more CAFs being reachable.
>
>
>
> Omer, maybe we are misunderstanding.   But if so, can you cast your question more precisely in terms of which lines of the wiki page or Note are you asking about?  And let’s make sure that the appropriate bit gets updated when you’ve nailed the answer
>
>
>
> Simon
>
>
>
> From: Simon Marlow <[hidden email]>
> Sent: 06 January 2020 18:17
> To: Simon Peyton Jones <[hidden email]>
> Cc: Ömer Sinan Ağacan <[hidden email]>; ghc-devs <[hidden email]>
> Subject: Re: Code generation/SRT question
>
>
>
> We have:
>
> * wiki: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts/storage/gc/cafs
>
> * a huge Note in CmmBuildInfoTables: https://gitlab.haskell.org/ghc/ghc/blob/master/compiler%2Fcmm%2FCmmBuildInfoTables.hs#L42
>
>
>
> Maybe we need links to these from other places?
>
>
>
> Omer's question is referring specifically to the [FUN] optimisation described in the Note.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Mon, 6 Jan 2020 at 17:50, Simon Peyton Jones <[hidden email]> wrote:
>
> Omer,
>
>
>
> I think I’m not understanding all the details, but I have a clear “big picture”.   Simon can correct me if I’m wrong.
>
>
>
> ·        The info table for any closure (top-level or otherwise) has a (possibly empty) Static Reference Table, SRT.
>
> ·        The SRT for an info table identifies the static top level closures that the code for that info table mentions.   (In principle the garbage collector could parse the code! But it’s easier to find these references if they in a dedicated table alongside the code.)
>
> ·        A top level closure is a CAF if it is born updatable.
>
> ·        A top level closure is CAFFY if it is a CAF, or mentions another CAFFY closure.
>
> ·        An entry in the SRT can point
>
> o   To a top-level updatable closure. This may now point into the dynamic heap, and is what we want to keep alive.  If the closure hasn’t been updated, we should keep alive anything its SRT points to.
>
> o   Directly to another SRT (or info table?) for a CAFFY top-level closure, which is a bit faster if we know the thing is non-updatable.
>
> ·        If a function f calls a top-level function g, and g is CAFFY, then f’s SRT should point to g’s closure or (if g is not a CAF) directly to its SRT.
>
> ·        If f is top level, and calls itself, there is no need to include a pointer to f’s closure in f’s own SRT.
>
> I think this last point is the one you are asking, but I’m not certain.
>
> All this should be written down somewhere, and perhaps is.  But where?
>
> Simon
>
>
>
> From: ghc-devs <[hidden email]> On Behalf Of Simon Marlow
> Sent: 06 January 2020 08:17
> To: Ömer Sinan Ağacan <[hidden email]>
> Cc: ghc-devs <[hidden email]>
> Subject: Re: Code generation/SRT question
>
>
>
> There's no need to set the srt field of f_info if f_closure is the SRT, since any reference to f_info in the code will give rise to a reference to f_closure in the SRT corresponding to that code fragment. Does that make sense?
>
>
>
> The use of a closure as an SRT is really quite a nice optimisation actually.
>
>
>
> Cheers
>
> Simon
>
>
>
> On Wed, 1 Jan 2020 at 09:35, Ömer Sinan Ağacan <[hidden email]> wrote:
>
> Hi Simon,
>
> In Cmm if I have a recursive group of functions f and g, and I'm using f's
> closure as the SRT for this group, should f's entry block's info table have
> f_closure as its SRT?
>
> In Cmm syntax
>
>      f_entry() {
>              { info_tbls: [...
>                            (c1vn,
>                             label: ...
>                             rep: ...
>                             srt: ??????]
>                stack_info: ...
>              }
>          {offset
>            c1vn:
>              ...
>          }
>      }
>
> Here should I have `f_closure` in the srt field?
>
> I'd expect yes, but looking at the current SRT code, in
> CmmBuildInfoTables.updInfoSRTs, we have this:
>
>   (newInfo, srtEntries) = case mapLookup (g_entry g) funSRTEnv of
>
>     Nothing ->
>       -- if we don't add SRT entries to this closure, then we
>       -- want to set the srt field in its info table as usual
>       (info_tbl { cit_srt = mapLookup (g_entry g) srt_env }, [])
>
>     Just srtEntries -> srtTrace "maybeStaticFun" (ppr res)
>       (info_tbl { cit_rep = new_rep }, res)
>       where res = [ CmmLabel lbl | SRTEntry lbl <- srtEntries ]
>
> Here we only update SRT field of the block if we're not adding SRT entries to
> the function's closure, so in the example above, because we're using the
> function as SRT (and adding SRT entries to its closure) SRT field of c1vn won't
> be updated.
>
> Am I missing anything?
>
> Thanks,
>
> Ömer

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs