Code generation/SRT question

Simon Peyton Jones simonpj at microsoft.com
Tue Jan 7 08:29:22 UTC 2020


|  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 <omeragacan at gmail.com>
|  Sent: 07 January 2020 05:59
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Simon Marlow <marlowsd at gmail.com>; ghc-devs <ghc-devs at haskell.org>
|  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 <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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2Fwikis%2Fcommentary%2Frts%2Fstorage%2Fgc%2
|  Fcafs&data=02%7C01%7Csimonpj%40microsoft.com%7Cba8ca780e8cb4803d53
|  008d79336b5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63713973549
|  8781862&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&data=02%7C01%7Csimonpj%40microsoft.com%7Cb
|  a8ca780e8cb4803d53008d79336b5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1
|  %7C0%7C637139735498781862&sdata=FymrjC9QgtuQM0AS0ZtV3yTec0hqFxYuKa
|  55XNqihNs%3D&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
|  <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


More information about the ghc-devs mailing list