What's preventing inlining GHC.Magic.lazy?

[Simon Peyton Jones]

Several points.

1. In GHC.Magic, the comments on lazyId say
-- Implementation note: its strictness and unfolding are over-ridden
-- by the definition in MkId.hs; in both cases to nothing at all.
-- That way, 'lazy' does not get inlined, and the strictness analyser
-- sees it as lazy.  Then the worker/wrapper phase inlines it.

The last line is not right: it's CorePrep that inlines it.  Fix?
Also point to `Note [lazyId magic]` in MkId


2. You ask
|  > > I'm trying to understand what's preventing inlining GHC.Magic.lazy.

The Note [lazyId magic] in MkId says:

* It must not have an unfolding: it gets "inlined" by a HACK in
  CorePrep. It's very important to do this inlining *after* unfoldings
  are exposed in the interface file.  Otherwise, the unfolding for
  (say) pseq in the interface file will not mention 'lazy', so if we
  inline 'pseq' we'll totally miss the very thing that 'lazy' was
  there for in the first place. See #3259 for a real world
  example.

Is that enough to explain?   Or, in the light of what you now know,
could you elaborate the explanation, so that it would have been
clearer the first time round?


3.  What is NOT said in Note [lazyId magic] is why we have a definition
in GHC.Magic.  There are two reasons I think:

* It generates Haddock docs.
* It generates code that may be called if CorePrep decides
  not to inline it.  Notably, if we have
     map lazy xs
  then CorePrep won't inline it.  So we need code to call.

Can you add this to `Note [lazyId magic]`.


4. Much of this now applies to `unsafeCorece#` too, and perhaps
   to other magicIds: see Note [magicIds] in MkId.

   Would you like to decide what can be described once, for
   each magicId, and what is specific to the particular magicId,
   and adjust the Notes in MkId accordingly?


Thanks

Simon


|  -----Original Message-----
|  From: Ömer Sinan Ağacan <omeragacan at gmail.com>
|  Sent: 17 July 2019 12:39
|  To: Matthew Pickering <matthewtpickering at gmail.com>
|  Cc: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs <ghc-
|  devs at haskell.org>
|  Subject: Re: What's preventing inlining GHC.Magic.lazy?
|  
|  Thanks Matt, that makes sense.
|  
|  I applied the same idea to another Id and now it's also never inlined
|  now, so I can confirm that this works.
|  
|  Ömer
|  
|  Matthew Pickering <matthewtpickering at gmail.com>, 17 Tem 2019 Çar,
|  11:05 tarihinde şunu yazdı:
|  >
|  > I think it doesn't get inlined because we don't add an unfolding in
|  > the definition of `lazyId` in `MkId`.
|  >
|  > The definition in `GHC.Magic` is just for documentation I think.
|  >
|  > Cheers,
|  >
|  > Matt
|  >
|  > On Wed, Jul 17, 2019 at 8:46 AM Ömer Sinan Ağacan
|  <omeragacan at gmail.com> wrote:
|  > >
|  > > Hi Simon,
|  > >
|  > > I'm trying to understand what's preventing inlining GHC.Magic.lazy.
|  > > I can see with -ddump-simpl -ddump-simpl-iterations -ddump-prep that
|  > > we only eliminate it in CorePrep, so it's preserved during
|  > > simplifications and tidying, but I don't see how. It doesn't have a
|  > > NOINLINE pragma, and we don't check whether the id we're inlining is
|  > > lazyId (using MkId.lazyId or MkId.lazyIdKey) anywhere in the compiler
|  as far as I can see.
|  > >
|  > > I also checked Note [lazyId magic] in MkId, but it doesn't explain
|  > > how we avoid inlining it.
|  > >
|  > > Could you say a few words on this?
|  > >
|  > > Thanks
|  > > Ömer
|  > > _______________________________________________
|  > > ghc-devs mailing list
|  > > ghc-devs at haskell.org
|  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
|  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%
|  > > 7C01%7Csimonpj%40microsoft.com%7C7854c360129d4ae5120408d70aab7481%7C
|  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636989603820519640&sd
|  > > ata=FwlftEXCI2Q%2FhYOotfuHISMSlCIFjVYgQcaXl16%2B0Ig%3D&reserved=
|  > > 0