Simon Are you the maintainer of the 'parallel' library? The core libraries wiki page says yes: https://wiki.haskell.org/Library_submissions#The_Core_Libraries But parallel.cabal says "Maintainer: libraries@haskell.orgmailto:libraries@haskell.org", which I thought we'd gotten rid of entirely. I ask because some should fix this: libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning: Rule "parList/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' We need a pragma on 'rseq'. Simon
On 30/07/2015 08:39, Simon Peyton Jones wrote:
Are you the maintainer of the ‘parallel’ library?
The core libraries wiki page says yes: https://wiki.haskell.org/Library_submissions#The_Core_Libraries
But parallel.cabal says “Maintainer: libraries@haskell.org mailto:libraries@haskell.org”, which I thought we’d gotten rid of entirely.
I ask because some should fix this:
libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning:
Rule "parList/rseq" may never fire
because ‘rseq’ might inline first
Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘rseq’
We need a pragma on ‘rseq’.
Ok, should it be INLINE[n] or NOINLINE[n], and what is the right value of n? (I always have to look up the documentation for these, just a suggestion but maybe it would be better to call them INLINEAFTER[n] and INLINEBEFORE[n], or something?) Cheers Simon
| Ok, should it be INLINE[n] or NOINLINE[n], and what is the right value | of n? Well it depends on the rules. The offending ones are below libraries/parallel/Control/Parallel/Strategies.hs:513:2: warning: Rule "parList/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' libraries/parallel/Control/Parallel/Strategies.hs:582:1: warning: Rule "evalBuffer/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' libraries/parallel/Control/Parallel/Strategies.hs:583:1: warning: Rule "parBuffer/rseq" may never fire because 'rseq' might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for 'rseq' All three appear to be always-active, and hence will run in the first phase (2). So delaying inlining rseq to phase 1 (phases count downwards) would do. So INLINE[1] or NOINLINE[1] | (I always have to look up the documentation for these, just a | suggestion but maybe it would be better to call them INLINEAFTER[n] | and INLINEBEFORE[n], or something?) Maybe. But NOINLINE[n] means "do not inline until phase n; and you are free to do what you like thereafter" So it would have to be NOINLINEUNTIL[n]. But yes, that'd be quite do-able. Simon | | Cheers | Simon
Hi, Am Donnerstag, den 30.07.2015, 10:14 +0000 schrieb Simon Peyton Jones:
| (I always have to look up the documentation for these, just a | suggestion but maybe it would be better to call them INLINEAFTER[n] | and INLINEBEFORE[n], or something?)
Maybe. But NOINLINE[n] means "do not inline until phase n; and you are free to do what you like thereafter" So it would have to be NOINLINEUNTIL[n]. But yes, that'd be quite do-able.
I support that suggestion, as I also always have to look it up as well, and things like NONLINE[~n] are really non-self-explanatory. Although "NOINLINEUNTIL[n]" is (to me, non-native-speaker) not as clear as it could be about what happens in phase n; the same with INLINEAFTER. How about this, using “from” and “before”, which (to me) make it clearer what happens at n: INLINE[n] becomes INLINEFROM[n] NOINLINE[n] becomes NOINLINEBEFORE[n] INLINE[~n] becomes INLINEBEFORE[n] NOINLINE[~n] becomes NOINLINEFROM[n] BTW, the docs say about NOINLINE “You shouldn't ever need to do this, unless you're very cautious about code size.” – should this also mention that NOINLINE are often necessary with RULES? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
| INLINE[n] becomes INLINEFROM[n] | NOINLINE[n] becomes NOINLINEBEFORE[n] | INLINE[~n] becomes INLINEBEFORE[n] | NOINLINE[~n] becomes NOINLINEFROM[n] I'd be fine with these. Maybe INLINE_FROM etc to split the words. If someone wants to - make a ticket - make a proposal and get feedback - implement, as synonyms for the existing things that'd be great. | BTW, the docs say about NOINLINE “You shouldn't ever need to do this, | unless you're very cautious about code size.” – should this also | mention that NOINLINE are often necessary with RULES? Good idea Simon
Hi, Am Donnerstag, den 30.07.2015, 10:28 +0000 schrieb Simon Peyton Jones:
If someone wants to - make a ticket - make a proposal and get feedback - implement, as synonyms for the existing things that'd be great.
https://ghc.haskell.org/trac/ghc/wiki/Proposal/SelfExplinatoryInlinePra gmas https://ghc.haskell.org/trac/ghc/ticket/10710 Feedback welcome! Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On 30/07/15 13:24, Joachim Breitner wrote:
BTW, the docs say about NOINLINE “You shouldn't ever need to do this, unless you're very cautious about code size.” – should this also mention that NOINLINE are often necessary with RULES?
unsafePerformIO is another popular and valid usecase for NOINLINE.
INLINE[n] becomes INLINEFROM[n] NOINLINE[n] becomes NOINLINEBEFORE[n]
INLINE[~n] becomes INLINEBEFORE[n]
NOINLINE[~n] becomes NOINLINEFROM[n]
Still not great, because INLINE[n] doesn't inline before phase n either. Maybe we should make that explicit, and use 2 separate pragmas: INLINE[n] becomes NO_INLINE_BEFORE[n], INLINE_FROM[n] NOINLINE[n] becomes NO_INLINE_BEFORE[n] INLINE[~n] becomes NO_INLINE_FROM[n], INLINE_BEFORE[n] NOINLINE[~n] becomes NO_INLINE_FROM[n] (a combination of NO_INLINE_BEFORE[n] and INLINE_BEFORE[n], or NO_INLINE_FROM[n] and INLINE_FROM[n], would be an error) If that is too verbose, we could make the 'no inline' part implicit: INLINE[n] becomes INLINE_FROM[n] NOINLINE[n] becomes INLINEABLE_FROM[n] INLINE[~n] becomes INLINE_BEFORE[n] NOINLINE[~n] becomes INLINEABLE_BEFORE[n]
Hi, Am Donnerstag, den 30.07.2015, 13:10 +0200 schrieb Thomas Miedema:
INLINE[n] becomes INLINEFROM[n] NOINLINE[n] becomes NOINLINEBEFORE[n] INLINE[~n] becomes INLINEBEFORE[n] NOINLINE[~n] becomes NOINLINEFROM[n]
Still not great, because INLINE[n] doesn't inline before phase n either. Maybe we should make that explicit, and use 2 separate pragmas:
INLINE[n] becomes NO_INLINE_BEFORE[n], INLINE_FROM[n] NOINLINE[n] becomes NO_INLINE_BEFORE[n] INLINE[~n] becomes NO_INLINE_FROM[n], INLINE_BEFORE[n] NOINLINE[~n] becomes NO_INLINE_FROM[n]
(a combination of NO_INLINE_BEFORE[n] and INLINE_BEFORE[n], or NO_INLINE_FROM[n] and INLINE_FROM[n], would be an error)
I thought about that as well, but I can only fight it with more verbosity: INLINE[n] becomes ONLY_INLINE_FROM[n] NOINLINE[n] becomes ONLY_NOINLINE_BEFORE[n] INLINE[~n] becomes INLINE_BEFORE[n] NOINLINE[~n] becomes NOINLINE_FROM[n] And I am not even sure if ONLY_INLINE_FROM has the connotation of definite inlining to every reader...
If that is too verbose, we could make the 'no inline' part implicit:
INLINE[n] becomes INLINE_FROM[n] NOINLINE[n] becomes INLINEABLE_FROM[n] INLINE[~n] becomes INLINE_BEFORE[n] NOINLINE[~n] becomes INLINEABLE_BEFORE[n]
But INLINABLE has its own semantics (i.e. “do retain a copy of the RHS”), and NOINLNE does, as far as I know, not imply this. But maybe your idea works with NOINLINE[n] becomes MAY_INLINE_FROM[n] NOINLINE[~n] becomes MAY_INLINE_BEFORE[n] and if we have that, how about INLINE[n] becomes MUST_INLINE_FROM[n] INLINE[~n] becomes MUST_INLINE_BEFORE[n] for symmetry as well? We’ll get a nice bikeshed out of this! Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
INLINE[n] becomes ONLY_INLINE_FROM[n] NOINLINE[n] becomes ONLY_NOINLINE_BEFORE[n] ... And I am not even sure if ONLY_INLINE_FROM has the connotation of definite inlining to every reader...
ONLY_INLINE_FROM is problematic indeed, because it could just as well mean the same as MAY_INLINE_FROM. I still think we should consider splitting up the original INLINE[n] pragma into two simpler pragmas (it currently does two things, whereas NOINLINE[n] does only one thing). Here' another suggestion (note that phases count down): INLINE[2] becomes NO_INLINE > 2, INLINE <= 2 NOINLINE[2] becomes NO_INLINE > 2 Or, if we don't want two separate pragmas: INLINE[2] becomes INLINE_IFF <= 2 NOINLINE[2] becomes NOINLINE > 2
Hi,
On Thu, Jul 30, 2015 at 1:22 PM, Joachim Breitner
But INLINABLE has its own semantics (i.e. “do retain a copy of the RHS”), and NOINLNE does, as far as I know, not imply this.
Ok.
But maybe your idea works with
NOINLINE[n] becomes MAY_INLINE_FROM[n] NOINLINE[~n] becomes MAY_INLINE_BEFORE[n]
Even better. INLINE[n] becomes MUST_INLINE_FROM[n]
INLINE[~n] becomes MUST_INLINE_BEFORE[n]
I added this option, without the `MUST_` (it doesn't add much in my opinion), as proposal 3 to https://ghc.haskell.org/trac/ghc/wiki/Proposal/SelfExplinatoryInlinePragmas .. Anyone have other suggestions? Thomas
participants (5)
-
Joachim Breitner -
Roman Cheplyaka -
Simon Marlow -
Simon Peyton Jones -
Thomas Miedema