On Tue, 7 Jan 2020 at 05:59, Ömer Sinan Ağacan <omeraga...@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 <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-devs@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 <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