Code generation/SRT question

Tue Jan 7 12:59:03 UTC 2020

On Tue, 7 Jan 2020 at 05:59, Ömer Sinan Ağacan <omeragacan at gmail.com> 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 <simonpj at microsoft.com>, 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 <marlowsd at gmail.com>
> > Sent: 06 January 2020 18:17
> > To: Simon Peyton Jones <simonpj at microsoft.com>
> > Cc: Ömer Sinan Ağacan <omeragacan at gmail.com>; ghc-devs <
> ghc-devs at haskell.org>
> > 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 <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/20200107/df2a5a1f/attachment.html>