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&
| ;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