RE: defunctionalization
It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I'd be happy to take it. (Don't forget the manual.) SImon From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Nicolas Frisby Sent: 16 July 2013 21:29 To: ghc-devs@haskell.org Subject: Re: defunctionalization Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn. On Jul 16, 2013 3:22 PM, Nicolas Frisby nicolas.fri...@gmail.commailto:nicolas.fri...@gmail.com wrote: I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Proposal: provide cas and barriers symbols even without -threaded
The atomic-primops library depends on symbols such as store_load_barrier and cas, which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT -threaded, the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign C' bits of this .cmm code: https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm I'm trying to explore hacks that will enable me to pull in those functions during compile time, without duplicating a whole bunch of code from the RTS. But it's a fragile business. It seems to me that some of these routines have general utility. In future versions of GHC, could we consider linking in those routines irrespective of -threaded? -Ryan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Future plans
Friends, For a number of reasons, I have decided to move on to new challenges, and so from the end of the month the GHC maintenance work will be taken over by other people within Well-Typed. I hope not to disappear completely, but in any case if there is anything you think only I might know, please tell me and I'll try to document it! A couple of topical items: First, I've written a brief summary of the GHC 7.8 release plans here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Please feel free to edit it if there's anything I've left out, or if there are any other errors. Second, there's been a bit of discussion recently about moving over to using git submodules for more repos, or using git subrepos instead, or merging some of our repos together. We didn't feel that there was a consensus on what to do, so we plan to do nothing for now, but this is an area that might want to be revisited after the 7.8 release. Finally, I would like to everyone at Well-Typed, the Simons, and too many other community members to list, for a fantastic seven years. It's been a pleasure working with you all, and I look forward to finding out where the future takes us. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Future plans
Ian, thank you for all you have doen for ghc! I am very grateful for this project and your contributions. Wish you all the best with your new adventure. Alexander On Thu, Jul 18, 2013 at 4:44 PM, Ian Lynagh i...@well-typed.com wrote: Friends, For a number of reasons, I have decided to move on to new challenges, and so from the end of the month the GHC maintenance work will be taken over by other people within Well-Typed. I hope not to disappear completely, but in any case if there is anything you think only I might know, please tell me and I'll try to document it! A couple of topical items: First, I've written a brief summary of the GHC 7.8 release plans here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Please feel free to edit it if there's anything I've left out, or if there are any other errors. Second, there's been a bit of discussion recently about moving over to using git submodules for more repos, or using git subrepos instead, or merging some of our repos together. We didn't feel that there was a consensus on what to do, so we plan to do nothing for now, but this is an area that might want to be revisited after the 7.8 release. Finally, I would like to everyone at Well-Typed, the Simons, and too many other community members to list, for a fantastic seven years. It's been a pleasure working with you all, and I look forward to finding out where the future takes us. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: provide cas and barriers symbols even without -threaded
I want to note something, which is that if we did link in cas/store_load_barrier, then your lockfree queue would always be synchronized, even if you didn't compile with -threaded. Perhaps this is not a big deal, but it is generally nice to not pay the cost of synchronization when it is unnecessary. So it would be better if there were threaded/nonthreaded variants which you could use instead. How does that sound? (Fortunately, you are not inlining the functions, so it's totally possible for this to happen. We'd have a tougher row to hoe if you needed to inline these functions.) Edward Excerpts from Ryan Newton's message of Thu Jul 18 06:17:44 -0700 2013: The atomic-primops library depends on symbols such as store_load_barrier and cas, which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT -threaded, the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign C' bits of this .cmm code: https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93c30b98c28c1d04f88781c/AtomicPrimops/cbits/primops.cmm I'm trying to explore hacks that will enable me to pull in those functions during compile time, without duplicating a whole bunch of code from the RTS. But it's a fragile business. It seems to me that some of these routines have general utility. In future versions of GHC, could we consider linking in those routines irrespective of -threaded? -Ryan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Future plans
+1 - very best of luck with your next endevour, and thanks so much for all your hard work over the years! Cheers, Tim On 18 Jul 2013, at 16:56, Alexander Kjeldaas wrote: Ian, thank you for all you have doen for ghc! I am very grateful for this project and your contributions. Wish you all the best with your new adventure. Alexander On Thu, Jul 18, 2013 at 4:44 PM, Ian Lynagh i...@well-typed.com wrote: Friends, For a number of reasons, I have decided to move on to new challenges, and so from the end of the month the GHC maintenance work will be taken over by other people within Well-Typed. I hope not to disappear completely, but in any case if there is anything you think only I might know, please tell me and I'll try to document it! A couple of topical items: First, I've written a brief summary of the GHC 7.8 release plans here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Please feel free to edit it if there's anything I've left out, or if there are any other errors. Second, there's been a bit of discussion recently about moving over to using git submodules for more repos, or using git subrepos instead, or merging some of our repos together. We didn't feel that there was a consensus on what to do, so we plan to do nothing for now, but this is an area that might want to be revisited after the 7.8 release. Finally, I would like to everyone at Well-Typed, the Simons, and too many other community members to list, for a fantastic seven years. It's been a pleasure working with you all, and I look forward to finding out where the future takes us. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: defunctionalization
What happens when you put NOINLINE on the function and compile with -fexpose-all-unfoldings? Does that get the behavior you want? On Thu, Jul 18, 2013 at 2:20 AM, Simon Peyton-Jones simo...@microsoft.comwrote: It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I’d be happy to take it. (Don’t forget the manual.) ** ** SImon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas Frisby *Sent:* 16 July 2013 21:29 *To:* ghc-devs@haskell.org *Subject:* Re: defunctionalization ** ** Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn. On Jul 16, 2013 3:22 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: defunctionalization
I think that would work, but I was looking for something more precise. On Thu, Jul 18, 2013 at 12:24 PM, Andrew Farmer afar...@ittc.ku.edu wrote: What happens when you put NOINLINE on the function and compile with -fexpose-all-unfoldings? Does that get the behavior you want? On Thu, Jul 18, 2013 at 2:20 AM, Simon Peyton-Jones simo...@microsoft.com wrote: It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I’d be happy to take it. (Don’t forget the manual.) ** ** SImon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas Frisby *Sent:* 16 July 2013 21:29 *To:* ghc-devs@haskell.org *Subject:* Re: defunctionalization ** ** Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn. On Jul 16, 2013 3:22 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: defunctionalization
This table outlines my plan for the compatibility of the pragmas. Each cell is formatted as x/y, where x answers Is the original RHS in the interface file? and y answers Will GHC try to inline it?. NOINLINE INLINABLE INLINE none no/no yes/yes yes/enthusiastically NOINLINE error yes/no error INLINABLE - error error INLINE - - error The proposed new yes/no option gives the GHC user more control. It prevents GHC from inlining a function while still supporting the ability to use the annotated function's RHS in another module, via SPECIALISE or the special inline function. Moreover, the presence of the RHS in the .hi file could be used by tools other than GHC like plugins or a super-compiler. On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones simo...@microsoft.comwrote: It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I’d be happy to take it. (Don’t forget the manual.) ** ** SImon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas Frisby *Sent:* 16 July 2013 21:29 *To:* ghc-devs@haskell.org *Subject:* Re: defunctionalization ** ** Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn. On Jul 16, 2013 3:22 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: defunctionalization
So the idea here to make it possible to have a function that can be specialized at certain types, and explicitly inlined at specific use sites, but ghc otherwise will not inline it? Cool! one thought: might it be simpler to instead have something like EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas which seem contradictory? On Thu, Jul 18, 2013 at 3:30 PM, Nicolas Frisby nicolas.fri...@gmail.comwrote: This table outlines my plan for the compatibility of the pragmas. Each cell is formatted as x/y, where x answers Is the original RHS in the interface file? and y answers Will GHC try to inline it?. NOINLINE INLINABLE INLINE none no/no yes/yes yes/enthusiastically NOINLINE error yes/no error INLINABLE - error error INLINE - - error The proposed new yes/no option gives the GHC user more control. It prevents GHC from inlining a function while still supporting the ability to use the annotated function's RHS in another module, via SPECIALISE or the special inline function. Moreover, the presence of the RHS in the .hi file could be used by tools other than GHC like plugins or a super-compiler. On Thu, Jul 18, 2013 at 4:20 AM, Simon Peyton-Jones simo...@microsoft.com wrote: It seems a little weird, but the internal data types can express it, so if you can make the front end do the right thing I’d be happy to take it. (Don’t forget the manual.) ** ** SImon ** ** *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Nicolas Frisby *Sent:* 16 July 2013 21:29 *To:* ghc-devs@haskell.org *Subject:* Re: defunctionalization ** ** Ah, I misread that TidyPgm function.It looks like if I build the CoreUnfolding, GHC will respect it. It's just rejecting the pragma combination in HsSyn. On Jul 16, 2013 3:22 PM, Nicolas Frisby nicolas.fri...@gmail.com wrote: I'd like to put a NOINLINE and an INLINABLE pragma on a binding. (I'm sketching a defunctionalization pass. I'd like the 'apply` routine RHS to make it into the interface file, but I do not want it to be inlined, since that'd undo the defunctionalization.) In other words, I'd like a CoreUnfolding value with the uf_guidance = UnfNever. It seems TidyPgm.addExternal ignores such a core unfolding. Would GHC consider a patch to make this work? Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
new pragma name ideas? (was: defunctionalization)
On Thu, Jul 18, 2013 at 5:10 PM, Carter Schonwald carter.schonw...@gmail.com wrote: So the idea here to make it possible to have a function that can be specialized at certain types, and explicitly inlined at specific use sites, but ghc otherwise will not inline it? Cool! one thought: might it be simpler to instead have something like EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas which seem contradictory? I like that idea. How about SPECIALISABLE? This is a nod to the possibility that GHC might someday automatically specialize an imported function. Or EXPOSE? Or EXTERNAL? Bikeshed activate! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: new pragma name ideas? (was: defunctionalization)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/07/13 23:18, Nicolas Frisby wrote: On Thu, Jul 18, 2013 at 5:10 PM, Carter Schonwald carter.schonw...@gmail.com wrote: So the idea here to make it possible to have a function that can be specialized at certain types, and explicitly inlined at specific use sites, but ghc otherwise will not inline it? Cool! one thought: might it be simpler to instead have something like EXPLICIT-INLINABLE, rather that requiring the juxtaposition of two pragmas which seem contradictory? I like that idea. How about SPECIALISABLE? This is a nod to the possibility that GHC might someday automatically specialize an imported function. Or EXPOSE? Or EXTERNAL? Bikeshed activate! ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs Maybe we need a BIKESHED pragma that will let us alias any extensions within the project to anything we like. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQIcBAEBAgAGBQJR6G1uAAoJEM1mucMq2pqXrbYP/RXWS0yeI6Ewy6hx35rmqxPG TfCK5U9KjW9WkvWXZqJq407Z0Qluiif0UIfMFy8oujj3RnjJUKN+1Co/zVdYxyiD 0LGdS4SxDQO4aRTd1uRAjaMGzVUA4xkAp+lQNI9jKN0ZojMiSQHXr4FoThkNTV1r wWUlYwTeDJlm1HJgqcNMIjhegeG1GJrmz3i5BZgW7WBI65TL/8MfwEozFO8jjtzD R44gF0sIg7rWEfzO3jFuhr+F3w9vwZ24KzAFPLjAIJlmB/YiBK7WwiIXI0tQhdg/ /72vVgQQMGsmSauZ0j2hjfImGDU45wLZ21w26/kkn7F6k9k+6BRFsedI1qI0Bf7V UqTG4oWLaZ5+EYQhvLH4VjYtH7h3UgGacHiYHcKHnmL49rr6GjDWQqBE8pieAtkQ ckhTw+fpMPQZd6T6J5OX5VNsnWcEG4C89PPCvYL9Jvw8tq6uzcTdRbxc+Thu3Plr I6hmcM5Ibz0n+nvqWLzsY/4voQb/CtiZWQQZ+c2VbIx1HpWsKTH0NFdHX891faTn ijsm8wsO0YcyvtlFPfZxKoQfb1GiBN+ttdlYStS7i15YmDujl7GYlXeHz0nr9FYv nNpHoNkz+U+fH3Neeh4epCOGxUhkAPWG/u1tMTAxQad0JiLpedKxB/IMBen+16pb IT4deYFnfsQjp/HAQfHQ =h5Nz -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
