RE: [Haskell] Expecting more inlining for bit shifting
[Redirecting to GHC users.] Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | [EMAIL PROTECTED] | Sent: 09 October 2006 00:41 | To: haskell@haskell.org | Subject: [Haskell] Expecting more inlining for bit shifting | | Consider the following GHC code: | | module Main where | | import GHC.Word | import GHC.Base | import GHC.Prim | import Random | | a `shiftRLT` b | b =# 32# = int2Word# 0# | | otherwise = a `uncheckedShiftRL#` b | | (W32# x#) `shift` (I# i#) | | i# =# 0#= W32# (narrow32Word# (x# `shiftL#` i#)) | | otherwise= W32# (x# `shiftRLT` negateInt# i#) | | x `shiftR` i = x `shift` (-i) | | shift7 x = x `shiftR` 7 | shift6 (W32# x) = (W32# (x `uncheckedShiftRL#` 6#)) | | main = do |xs - sequence (replicate 100 |(fmap (shift7 . fromIntegral) (randomIO::IO Int))) |print (sum xs) | | I have copied the definition of `shiftR` for Word32 into this file. | | Suppose we want to shift a series of numbers by 7 bits. One would expect | GHC's inliner to notice that (-7) is indeed not greater than 0, and | eliminate the branch in the definition of `shift`. Further one would | expect GHC to notice that 7 is indeed not gtreater than 32, and eliminate | the branch in shiftRLT. Thus one would expect the code generated by using | shift7 to be identical to that being generated by shfit6 (with 7 replaced | by 6). | | But this appears not to be the case. The code generated for shift7 (if I | can read the C code correctly) is: | Sp[-1] = (-0x7U); | Sp[-2] = R1.p[1]; | *Sp = (W_)s2za_info; | Sp=Sp-2; | JMP_((W_)Main_zdwshift_info); | | while the code generated for shift6 is the lovely: | | Hp=Hp+2; | if ((W_)Hp (W_)HpLim) goto _c2Aa; | _s2xq = (R1.p[1]) 0x6U; | Hp[-1] = (W_)GHCziWord_W32zh_con_info; | *Hp = _s2xq; | R1.p=Hp-1; | Sp=Sp+1; | JMP_(*Sp); | _c2Aa: | HpAlloc = 0x8U; | JMP_(stg_gc_enter_1); | | My question is, why the discrepency? | | -- | Russell O'Connor http://r6.ca/ | ``All talk about `theft,''' the general counsel of the American Graphophone | Company wrote, ``is the merest claptrap, for there exists no property in | ideas musical, literary or artistic, except as defined by statute.'' | ___ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
Duncan Coutts schrieb:
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
A simple script for the pgmF command
The only disadvantage is that the filename in error and warning messages
is quite useless:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
May it be that import chasing takes longer now? I noticed quite a gap
before ghc started to compile my 624 modules.
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Keyword foreign
Could some add to the user guide at: http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html#options-language that -ffi and -fffi is (currently) implied by -fglasgow-exts? (as stated in the flag reference) in the same way as it is stated under -fimplicit-params or -fth in section 7.1. Language options? Therefore the keyword foreign gets into scope by -fglasgow-exts. And maybe this word and others should be added to http://haskell.org/haskellwiki/Keywords, because forall is listed and only available with -fglasgow-exts? Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Keyword foreign
Hi Therefore the keyword foreign gets into scope by -fglasgow-exts. And maybe this word and others should be added to http://haskell.org/haskellwiki/Keywords, because forall is listed and only available with -fglasgow-exts? It's a wiki, so feel free. I set up the original version using the keywords from the Haskell 98 report, and have little knowledge of the GHC extension keywords - help is welcome. (While you're at it you can always expand on some of the existing keywords as well, some are taken directly from the H98 report and are a bit dry :) ) Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
On Mon, Oct 09, 2006 at 10:33:47AM -0400, [EMAIL PROTECTED] wrote: On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: Turns out that 'shift' is just too big to be inlined. (It's only called once, but you have exported it too.) You can see GHC's inlining decisions by saying -ddump-inlinings. To make GHC keener to inline, use an INLINE pragma, or increase the inlining size threshold e.g. -funfolding-threshold=12 Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? It might be possible, but it sounds tricky. I guess it would have to go something like try inlining this, run the simplifier, see if it got small enough, if not back out, which could waste a lot of work if it fails in lots of cases. PS, is there a way to mark an imported instance of a class function (Data.Bits.shift for Data.Word.Word32) to be inlined? You can use GHC.Exts.inline in 6.6: http://www.haskell.org/ghc/dist/current/docs/users_guide/special-ids.html#id3178018 but note the restriction in the final paragraph. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] Expecting more inlining for bit shifting
For small functions, GHC inlines them rather readily. For big functions GHC doesn't inline them. For medium-sized functions, GHC looks at the arguments; if they look interesting (e.g. are a constant) then it inlines the function. So the behaviour you want will happen for certain settings of the unfolding-use-threshold. But at the moment there is no way to add a pragma saying inline if my second argument is a constant. One could imagine such a thing, but it's not there today, I'm afraid. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | Sent: 09 October 2006 15:08 | To: Simon Peyton-Jones | Cc: GHC users | Subject: RE: [Haskell] Expecting more inlining for bit shifting | | On Mon, 9 Oct 2006, Simon Peyton-Jones wrote: | | Turns out that 'shift' is just too big to be inlined. (It's only called | once, but you have exported it too.) | | You can see GHC's inlining decisions by saying -ddump-inlinings. | | To make GHC keener to inline, use an INLINE pragma, or increase the | inlining size threshold e.g. -funfolding-threshold=12 | | Okay, when I force inlining for shift, (and I even need to do it for | shiftR!) then the code is inlined in C. However this isn't the behaviour | I want. Ideally the inlining should only happen when/because the second | argument of shift is constant and the system knows that it can evaluate | the case analysis away and that makes the function small. | | Am I being too naive on what to expect from my complier or is this | reasonable? | | PS, is there a way to mark an imported instance of a class function | (Data.Bits.shift for Data.Word.Word32) to be inlined? | | -- | Russell O'Connor http://r6.ca/ | ``All talk about `theft,''' the general counsel of the American Graphophone | Company wrote, ``is the merest claptrap, for there exists no property in | ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: UTF-8 decoding error
On Mon, 2006-10-09 at 13:55 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
A simple script for the pgmF command
The only disadvantage is that the filename in error and warning messages
is quite useless:
I think you can fix this by pre-pending a {-# LINE #-} pragma in your
script. Something like:
May it be that import chasing takes longer now? I noticed quite a gap
before ghc started to compile my 624 modules.
Yes, since it has to run the pre-processor before it can look at the
imports.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Expecting more inlining for bit shifting
Okay, when I force inlining for shift, (and I even need to do it for shiftR!) then the code is inlined in C. However this isn't the behaviour I want. Ideally the inlining should only happen when/because the second argument of shift is constant and the system knows that it can evaluate the case analysis away and that makes the function small. Am I being too naive on what to expect from my complier or is this reasonable? It might be possible, but it sounds tricky. I guess it would have to go something like try inlining this, run the simplifier, see if it got small enough, if not back out, which could waste a lot of work if it fails in lots of cases. I would have imagined an optimisation step that only activates when a constructor is passed into a function to see if it produces a branch that can be precomputed, and then tries to determine if it is worth making a specialized function with that case eliminated. Or possibly having each function inspected to see if it has branches that could be eliminated if a constructor was passed as an argument. I must say I'm extremely disappointed with this. I believe I was taught in my undergraduate CS program (but perhaps I wasn't) that one ought not to make these sorts of trivial hand optimisations, because compilers are smart enough to figure out these sorts of things by themselves, and they know more about that target platform that you do. In particular the propaganda about side-effect-free functional languages was a promise that they would use the strong types and side-effect-freeness to do all sorts of wonderful optimisations. However, it seems the truth of the matter is that an advanced compiler such as GHC cannot even optimise away the bounds checks occurring when shifting by a constant number of bits. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problem with ghc-6.5.20061008 on Mac OS X Intel
Hi, I was able to build this release using the 20060915 Intel build that's available, on 10.4.8. ghci seems to work OK (except for Readline), but an attempt to compile gives: $ ghc example25.hs /usr/bin/ld: Undefined symbols: _mtlzm1zi0_ControlziMonadziState_evalStateT_closure _mtlzm1zi0_ControlziMonadziState_gets_closure _mtlzm1zi0_ControlziMonadziState_zdf1_closure _mtlzm1zi0_ControlziMonadziState_zdf7_closure _mtlzm1zi0_ControlziMonadziState_zdf9_closure _mtlzm1zi0_ControlziMonadziWriter_zdf5_closure _mtlzm1zi0_ControlziMonadziWriter_zdf7_closure collect2: ld returned 1 exit status This didn't happen before. Any ideas? Am I doing something wrong, or is there something wrong with the 20061008 snapshot? Thanks, Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with ghc-6.5.20061008 on Mac OS X Intel
Thanks, Spencer Janssen already set me straight. It was indeed the lack of --package mtl. I'm pretty sure I didn't have that before, but my memory could be faulty. Thanks again, Deborah On Oct 9, 2006, at 5:57 PM, Ian Lynagh wrote: On Mon, Oct 09, 2006 at 05:42:14PM -0700, Deborah Goldsmith wrote: I was able to build this release using the 20060915 Intel build that's available, on 10.4.8. ghci seems to work OK (except for Readline), That sounds like good news, thanks :-) but an attempt to compile gives: $ ghc example25.hs /usr/bin/ld: Undefined symbols: _mtlzm1zi0_ControlziMonadziState_evalStateT_closure _mtlzm1zi0_ControlziMonadziState_gets_closure _mtlzm1zi0_ControlziMonadziState_zdf1_closure _mtlzm1zi0_ControlziMonadziState_zdf7_closure _mtlzm1zi0_ControlziMonadziState_zdf9_closure _mtlzm1zi0_ControlziMonadziWriter_zdf5_closure _mtlzm1zi0_ControlziMonadziWriter_zdf7_closure collect2: ld returned 1 exit status This didn't happen before. Any ideas? Am I doing something wrong, or is there something wrong with the 20061008 snapshot? Are you sure it used to work before, exactly like that? It looks like it is failing to link because you didn't use -package mtl or --make. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with ghc-6.5.20061008 on Mac OS X Intel
Hi Deborah, The first thing that springs to mind is that the mtl library (which contains Control.Monad.State, the source of the link errors below) isn't included in the 20060915 binary distribution, though it should be easy to check it out and compile it separately. So, the question is, why does it get all the way to link time before noticing that the library isn't available? It's possible that one version of GHC is trying to use object or library files created by another version. I came across that problem myself, at one point. You might check that only one copy of the ghc-6.5/lib/ directory exists anywhere that GHC might find it. When you say this didn't happen before, do you mean that the 20060915 build can compile example25.hs, but trying to compile it with your own build of 20061008 fails as you've described? By the way, does readline work for you with the ghci from the 20060915 binary distribution, and just not with the version you compiled yourself? I ask because one of the people I was talking to as I build the distribution had trouble with it. Aaron On Oct 9, 2006, at 5:42 PM, Deborah Goldsmith wrote: Hi, I was able to build this release using the 20060915 Intel build that's available, on 10.4.8. ghci seems to work OK (except for Readline), but an attempt to compile gives: $ ghc example25.hs /usr/bin/ld: Undefined symbols: _mtlzm1zi0_ControlziMonadziState_evalStateT_closure _mtlzm1zi0_ControlziMonadziState_gets_closure _mtlzm1zi0_ControlziMonadziState_zdf1_closure _mtlzm1zi0_ControlziMonadziState_zdf7_closure _mtlzm1zi0_ControlziMonadziState_zdf9_closure _mtlzm1zi0_ControlziMonadziWriter_zdf5_closure _mtlzm1zi0_ControlziMonadziWriter_zdf7_closure collect2: ld returned 1 exit status This didn't happen before. Any ideas? Am I doing something wrong, or is there something wrong with the 20061008 snapshot? Thanks, Deborah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem with ghc-6.5.20061008 on Mac OS X Intel
Strange. Should it really get to link time before it notices that you haven't used the necessary --package flags? I would have expected an error earlier on. Aaron On Oct 9, 2006, at 6:03 PM, Deborah Goldsmith wrote: Thanks, Spencer Janssen already set me straight. It was indeed the lack of --package mtl. I'm pretty sure I didn't have that before, but my memory could be faulty. Thanks again, Deborah On Oct 9, 2006, at 5:57 PM, Ian Lynagh wrote: On Mon, Oct 09, 2006 at 05:42:14PM -0700, Deborah Goldsmith wrote: I was able to build this release using the 20060915 Intel build that's available, on 10.4.8. ghci seems to work OK (except for Readline), That sounds like good news, thanks :-) but an attempt to compile gives: $ ghc example25.hs /usr/bin/ld: Undefined symbols: _mtlzm1zi0_ControlziMonadziState_evalStateT_closure _mtlzm1zi0_ControlziMonadziState_gets_closure _mtlzm1zi0_ControlziMonadziState_zdf1_closure _mtlzm1zi0_ControlziMonadziState_zdf7_closure _mtlzm1zi0_ControlziMonadziState_zdf9_closure _mtlzm1zi0_ControlziMonadziWriter_zdf5_closure _mtlzm1zi0_ControlziMonadziWriter_zdf7_closure collect2: ld returned 1 exit status This didn't happen before. Any ideas? Am I doing something wrong, or is there something wrong with the 20061008 snapshot? Are you sure it used to work before, exactly like that? It looks like it is failing to link because you didn't use -package mtl or --make. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
