Code generation/SRT question

[Simon Marlow]

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/20200106/68fc285f/attachment.html>