| a) If the INLINE pragma is such a commandment, why don't we respect it with | -O0?
We ignore pragmas with -O0. | b) Would it be sensible to only inline in scrutinee (`case <id> of | ...`) context, to avoid duplication? After all it's the guts of the value | we are interested in, not the whole package. That's what happened before but see Note [Honour INLINE on 0-ary bindings] in CoreUnfold and Trac #15578 | c) Could a global CSE pass pick up the floated-out value and revert it to | the original imported identifier? CSE does not currently do CSE with imported unfoldings. It would be possible, but perhaps expensive, to do so. | d) Or should be simply remove the INLINE pragmas from the library (0-ary | objects)? Possibly changing to INLINABLE? I have absolutely no idea why it is there. I bet that removing it is the right thing to do. S | -----Original Message----- | From: Gabor Greif <[email protected]> | Sent: 08 January 2019 10:06 | To: Mikolaj Konarski <[email protected]> | Cc: Simon Peyton Jones <[email protected]>; ghc-devs <ghc- | [email protected]> | Subject: Re: [Q] Inlining done: evtRead | | Thanks Mikolaj and Simon, | | this explains it. I'll study the related ticket next. Still, the floating- | out related duplication aspect looks like a problem, or would you disagree? | I mean, | | a) If the INLINE pragma is such a commandment, why don't we respect it with | -O0? | b) Would it be sensible to only inline in scrutinee (`case <id> of | ...`) context, to avoid duplication? After all it's the guts of the value | we are interested in, not the whole package. | c) Could a global CSE pass pick up the floated-out value and revert it to | the original imported identifier? | d) Or should be simply remove the INLINE pragmas from the library (0-ary | objects)? Possibly changing to INLINABLE? | | Just thinking out loud, as this appears like a pessimisation to me. | | Cheers, | | Gabor | | On 1/8/19, Mikolaj Konarski <[email protected]> wrote: | > On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif <[email protected]> wrote: | >> | >> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the | >> inliner to respect the pragma? | > | > Yes: | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | > ab.haskell.org%2Fghc%2Fghc%2Fcommit%2Fb9b1f99954e69f23e9647d00e048938d | > 5509ec14&data=02%7C01%7Csimonpj%40microsoft.com%7Ca24c2089a67d4377 | > 39aa08d67550e5a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63682538 | > 7644348465&sdata=qhyHG6VD1%2B9Mkrjwzt7DcTYFVPhtVosdTdhSCJwExSA%3D& | > amp;reserved=0 | > | > But it's not on 8.6 branch (yet?). | > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
