Code generation/SRT question

[Simon Marlow]

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 <simonpj at microsoft.com>
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 <ghc-devs-bounces at haskell.org> *On Behalf Of *Simon
> Marlow
> *Sent:* 06 January 2020 08:17
> *To:* Ömer Sinan Ağacan <omeragacan at gmail.com>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *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 <omeragacan at gmail.com>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200106/2292ddda/attachment.html>