On Wed, Aug 04 2021, Carter Schonwald wrote:

I’m not sure about the pragma debugging, but are you using it in point free style? Cause I’m that case it may not be inclined because it’s not being fully applied on the left hand side?

Good point, but I checked, and it's fully applied. :-( I should also note that, with the inline check, I've also tried: {-# OPTIONS_GHC -dinline-check &&& #-} {-# OPTIONS_GHC -dinline-check (&&&) #-} ... to no avail. -- Regards, Mike

It's hard to tell what is happening without a repro case. Can you share one? You suggested that it might have something to do with using an operator. Does the same thing happen if you replace the operator with an alpha-numeric name? Simon | -----Original Message----- | From: Glasgow-haskell-users | On Behalf Of Michael Sperber | Sent: 06 August 2021 13:44 | To: glasgow-haskell-users@haskell.org | Subject: Re: -dinline-check for symbolic names? | | [You don't often get email from sperber@deinprogramm.de. Learn why this | is important at http://aka.ms/LearnAboutSenderIdentification.] | | On Fri, Aug 06 2021, Michael Sperber wrote: | | > On Wed, Aug 04 2021, Carter Schonwald | wrote: | > | >> I'm not sure about the pragma debugging, but are you using it in | >> point free style? Cause I'm that case it may not be inclined because | >> it's not being fully applied on the left hand side? | > | > Good point, but I checked, and it's fully applied. :-( | | Another note: Once I change the INLINE to INLINE [0], everything works: | (&&&) gets inlined, and -dinline-check works. Explanation welcome ... | | -- | Regards, | Mike | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell- | users&data=04%7C01%7Csimonpj%40microsoft.com%7C7b8c76634e3c4ce86a7008 | d958d801ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63763850704993823 | 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=DZHraN9nVbZMWxmekmYP2sAqRBh1qNbVWUlo | JQdKnkc%3D&reserved=0

| First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? Yes. The last one wins. This should be in the user manual. Would anyone like to offer a PR? | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the simplifier pass inserted by the ConCat plugin. (And | hence INLINE [0] moved it out of that pass.) Is it possible that the flag | isn't getting propagated there? I don't see how that could happen, but I only have a vague idea of what is going on. Simon | -----Original Message----- | From: Michael Sperber | Sent: 18 August 2021 14:14 | To: Simon Peyton Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: -dinline-check for symbolic names? | | | On Tue, Aug 10 2021, Simon Peyton Jones wrote: | | > It's hard to tell what is happening without a repro case. Can you share | one? | | Haven't been able to do that with <10MB of output, I'm afraid ... | | > You suggested that it might have something to do with using an | > operator. Does the same thing happen if you replace the operator with | > an alpha-numeric name? | | I've now concluded several things are coming together. As things started | working with INLINE [0] instead of INLINE, it's not the symbolic name. | | First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? | | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the simplifier pass inserted by the ConCat plugin. (And | hence INLINE [0] moved it out of that pass.) Is it possible that the flag | isn't getting propagated there? | | (Sorry for being vague - if you don't know offhand, it's not worth digging | without more info from me.) | | -- | Regards, | Mike