What's preventing inlining GHC.Magic.lazy?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

What's preventing inlining GHC.Magic.lazy?

Ömer Sinan Ağacan
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What's preventing inlining GHC.Magic.lazy?

Matthew Pickering
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 <[hidden email]> 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: What's preventing inlining GHC.Magic.lazy?

Ömer Sinan Ağacan
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 <[hidden email]>, 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 <[hidden email]> 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: What's preventing inlining GHC.Magic.lazy?

GHC - devs mailing list
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 <[hidden email]>
|  Sent: 17 July 2019 12:39
|  To: Matthew Pickering <[hidden email]>
|  Cc: Simon Peyton Jones <[hidden email]>; ghc-devs <ghc-
|  [hidden email]>
|  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 <[hidden email]>, 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
|  <[hidden email]> 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
|  > > [hidden email]
|  > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmai
|  > > l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&amp;data=02%
|  > > 7C01%7Csimonpj%40microsoft.com%7C7854c360129d4ae5120408d70aab7481%7C
|  > > 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636989603820519640&amp;sd
|  > > ata=FwlftEXCI2Q%2FhYOotfuHISMSlCIFjVYgQcaXl16%2B0Ig%3D&amp;reserved=
|  > > 0
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs