October 2006 - Glasgow-haskell-users

RE: [Haskell] Expecting more inlining for bit shifting
by Simon Peyton-Jones 09 Oct '06

09 Oct '06

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: roconnor(a)theorem.ca [mailto:roconnor@theorem.ca] | 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.''

1 0

Keyword foreign
by Christian Maeder 09 Oct '06

09 Oct '06

Could some add to the user guide at: http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-featur… 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

2 1

ANNOUNCE: GHC 6.6 Second Release Candidate
by Ian Lynagh 09 Oct '06

09 Oct '06

We are pleased to announce the Second Release Candidate phase for GHC 6.6. Snapshots beginning with 6.5.20061001 are release candidates for 6.6 We would be particularly interested to hear whether or not the 6.6 RC works for people who were having trouble with 6.4.2. Also, please note that the GHC API has changed since the last RC as a result of some feedback from the Hackathon, so you may want to check that any applications using it still work. Download snapshots from here: http://www.haskell.org/ghc/dist/current/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src.tar.bz2 http://www.haskell.org/ghc/dist/current/dist/ghc-6.5.20061001-src-extralibs… Only the first of these is necessary. The "extralibs" package contains various extra packages that we normally supply with GHC (and a couple of new ones) - unpack the extralibs tarball on top of the source tree to add them, they will be included in the build automatically. There are also currently binary distributions for x86_64/Linux (Fedora Core 5), i386/Linux (RedHat 7(!)), and Windows. More may appear later. Please test as much as possible, bugs are much cheaper if we find them before the release! We expect to release in about a week's time. Thanks Ian

8 15

RE: [Haskell] Expecting more inlining for bit shifting
by Simon Peyton-Jones 09 Oct '06

09 Oct '06

[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: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | roconnor(a)theorem.ca | Sent: 09 October 2006 00:41 | To: haskell(a)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 1000000 | (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(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

ghc 6.6 user guide on haskell.org
by Bulat Ziganshin 09 Oct '06

09 Oct '06

Hello glasgow-haskell-users, i don't see updates in ghc 6.6 users guide on the haskell.org (for example, http://www.haskell.org/ghc/dist/current/docs/users_guide/ghc-language-featu… still contains "-fno-monomorphism-restriction,-fno-monomorphism-restriction" line). can you please restore automatic updates of these pages with current changes in users guide? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

GHC API: Problems with implementing ":reload" for "ghc --make"
by Brian Smith 09 Oct '06

09 Oct '06

Hello all, My goal is to write a program GhcRemake that works like "ghc --make." However, instead of terminating after compilation is done, I want the program to stay open and wait for me to hit <ENTER>. When I hit <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc --make" again with the same arguments. The benefit of such a program is that GhcRemake should be able to cache a lot of data in memory between invocations and hopefully be able to do the subsequent re-makes much faster. I tried to do this by using the GHC API, and doing the initial build and all subsequent builds in the same session. My program seems to work fine when run on itself and when run on Cabal. But, these two packages seem to be too small to notice any reduction of building time. So, I decided to test my program by building the GHC API with it. Unfortunately, it seems like every build after the first one in the session does the dependency analysis badly, and things get recompiled unnecessarily. In the tests below, you can tell when things get recompiled because you will see a lot of warning messages (due to the -W parameter). Probably this is due to a mistake on my part but I can't figure out what it is. I would be very grateful if somebody could point out what I am doing wrong or what the problem is. I basically copied 90% of the code for the program from GHC's Main.hs, so it should be familiar to people on the GHC team. You need to be using a recent GHC 6.5. snapshot for everything described below. Here is the test procedure: 1. I run the program and it will do the intial make, just like ghc --make does. 2. I quit the program (type "quit" <ENTER>). 3. I run the program. It notices that nothing needs to be recompiled. 4. I quit the program. 5. I run ghc --make. It notices that nothing needs to be recompiled. 6. I run the program again, and it notices that nothing needs to be recompiled. 7. Instead of quitting, I hit <ENTER> to re-make the library. But now, GhcRemake thinks that a lot of things need to be recompiled. It should notice that nothing needs to be recompiled. 8. After I let it recompile, I hit <ENTER> to re-make the library again. But, again, it things a lot of things need to be recompiled. Again, it should notice that nothing needs to be recompiled. 9. I quit the program (type "quit" <ENTER>). 10. now I run a ghc --make. But, ghc --make things things need to be recompiled too. It should have noticed that nothing needs to be recompiled. 11. If I run the program again, it notices that nothing needs to be recompiled. 12. But, if I hit <ENTER> to re-make the program, it suddenly thinks that many source files need to be compiled. It should have noticed that nothing needs to be recompiled. The ghc --make command I am using to build the GHC API is: cd ghc/compiler ghc --make GHC -package-name ghc -package base -package template-haskell -package Cabal -package Win32 -package regex-compat -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -fglasgow-exts -fno-generics -DBREAKPOINT -DDEBUG -recomp -cpp -include"cutils.h" -Istage2 -I. -Iparser -keep-tmp-files -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -icoreSyn -ispecialise -isimplCore -istranal -isimplStg -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -ighci -ideSugar -icodeGen -inativeGen -icmm -istgSyn To build my program, you just need to change the pathToGHC variable in its source code, and then use ghc --make: ghc --make -fffi GhcRemake -package ghc -package Cabal or you can use Cabal: runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install Then, to run my program, just give it the same arguments as you gave "ghc --make" (without "--make"): cd ghc/compiler path/to/GhcRemake.exe GHC -package-name ghc -package base -package template-haskell -package Cabal -package Win32 -package regex-compat -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -fglasgow-exts -fno-generics -DBREAKPOINT -DDEBUG -recomp -cpp -include"cutils.h" -Istage2 -I. -Iparser -keep-tmp-files -iutils -ibasicTypes -itypes -ihsSyn -iprelude -irename -itypecheck -icoreSyn -ispecialise -isimplCore -istranal -isimplStg -imain -iprofiling -iparser -icprAnalysis -indpFlatten -iiface -ighci -ideSugar -icodeGen -inativeGen -icmm -istgSyn BTW, I am planning to extend this program in many ways in the future, including a ":make" command for GHCi, an "--interactive --make" mode for GHC itself. Eventually, I would like to implement a "quick error checking with automatic background compilation" mode as well. Thanks, Brian Smith

1 0

4th Cabal-1.1.6 release candiate
by Duncan Coutts 07 Oct '06

07 Oct '06

Hi all, I've put up a tarball for the fourth 1.16 Cabal release candidate: http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz I had been hoping that this would be the final RC. One bug I've uncovered is that building the haddock docs for HUnit when cpphs is installed fails. This is because the Distribution.PreProcess.Unlit.unlit code produces incorrect output for Test/HUnit/Lang.lhs. I could do with some help in fixing this. One can reproduce it with: cd libraries/HUnit cpphs -OLang.lhs Test/HUnit/Lang.lhs --noline --strip -D__GLASGOW_HASKELL__=605 -D__HADDOCK__ ghc -e 'interact (Distribution.PreProcess.Unlit.unlit "Lang.lhs")' < Lang.lhs > Lang.hs compare this with: ghc -E Lang.lhs -o Lang.hspp and try: diff Lang.hspp Lang.hs Cabal's unlit code is incorrectly dropping whitespace and actual tokens. See especially the last part of that file. I think this needs fixing asap since the cpphs code path gets used in preference to the ghc -E path if cpphs is installed. In this example the symptoms are not too bad as it seems only to be affecting haddock, but I fear it may break more seriously in other packages. Duncan

1 0

building GHC (head) on windows MINGW: HsRegexPosixConfig.h: No such file or directory
by Rene de Visser 05 Oct '06

05 Oct '06

Hello, What do I need to install for the regex library support on MINGW? It looks like the regex library needs the posix library, and in my MINGW / MSYS installation I don't find one (and neither does configure). Rene.

3 3

core lib attempt#2: problem with hard-wired module names for classes in GHC
by Bulat Ziganshin 05 Oct '06

05 Oct '06

Hello glasgow-haskell-users, i'm now trying to rewrite GHC.* in more portable fashion, "boxifying" all the definitions in hope that smart compiler will unbox them itself of course, i'm using -fno-implicit-prelude and have found some more things that still hard-wired into compiler: 'c' syntax creates GHC.Base.Char instead of Char [a..b] requires instance of GHC.Enum.Enum it will be great to fix this (i will make ticket), but that is not show-stopper the problem that i'd imagined is how this new cool base library can be used with existing GHC version? of course, users will not use -fno-implicit-prelude, so their apps will expect that Enum class is defined in GHC.Enum and no other place. or it can just re-export class defined in some other module, say Core.Enum? even more problems with GHC.Base mpdule which should define both some hard-wired types and classes what means that we can't move out of this package some intermediate code (at least, without using recursive modules) about core library attempt#2 - the main problem in bootstrapping Haskell libs (for any compiler) is the expressiveness problem - for example, in order to define "instance Show Int", you need to use '/' operation which is defined in Integral class that in turn requires Show instance. GHC solves this problem by omitting use of classes in low-level modules and switching to the # operations. this perfectly works, but don't compatible with other compilers. what are other possible solutions? 1) lift all the # operations to the corresponding operations on boxed types and change low-level modules so they work with these un-classified but boxed operations, so the following: GHC.Base: divInt (I# a) (I# b) | gtInt# a b = mulInt# a b turns into: GHC.Base: gtInt (I# a) (I# b) = gtInt# a b mulInt (I# a) (I# b) = mulInt# a b Core.Base: divInt a b | gtInt a b = mulInt a b 2) another solution is to bring together definitions of Show/Enum/Num/Integral classes and their Int/Integer instances in one large module. after all, by the limiting it to only Int/Integer instances, its size should be reasonable. This will allow to use "natural" definitions (i.e. use '*' and '>' operators), although i fear that this can produce slower code. in particular, this can create circular dictionary dependencies (i.e. Show Int instance depends on Num Int and vice versa, which, according to my experience, prevents inlining of all methods (!) in both classes; although my experience was with parameterized instances (i.e. like Show [a] <=> Num [a]), so may be it will be not a problem here) it seems that integer literals in Hugs completely don't work before introduction of fromInteger operation. so it seems that the second way is the only really possible one :) it will be great to hear critics before i will invest time in implementing second plan. as a first result, i plan to refactor GHC.Base, Show, Enum, Num, Real modules into somewhat implementing the same facilities but compatible with Hugs. i think that this will make a solid foundation for future co-development of core lib -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 3

Controlling -fno-unit-at-a-time
by Ravi Nanavati 05 Oct '06

05 Oct '06

If I understand the way things work, GHC decides whether or not to emit the -fno-unit-at-a-time flag in -fvia-C compilation based on whether or not the gcc used when compiling GHC supported the flag or not. I'm running into trouble using precompiled GHC snapshots (that were compiled on machines whose gcc supports -fno-unit-at-a-time) on a machine whose gcc doesn't support it (a gcc 3.2 version, I believe). Is there any way force GHC to not emit the flag (short of recompiling from source)? Thanks, - Ravi

4 3