| 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 <omeraga...@gmail.com> | Sent: 07 January 2020 05:59 | To: Simon Peyton Jones <simo...@microsoft.com> | Cc: Simon Marlow <marlo...@gmail.com>; ghc-devs <ghc-devs@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 <simo...@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 <marlo...@gmail.com> | > Sent: 06 January 2020 18:17 | > To: Simon Peyton Jones <simo...@microsoft.com> | > Cc: Ömer Sinan Ağacan <omeraga...@gmail.com>; ghc-devs <ghc- | d...@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 | <simo...@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-boun...@haskell.org> On Behalf Of Simon | Marlow | > Sent: 06 January 2020 08:17 | > To: Ömer Sinan Ağacan <omeraga...@gmail.com> | > Cc: ghc-devs <ghc-devs@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 | <omeraga...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs