Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
On 08/03/14 07:19, Erik de Castro Lopo wrote: Mateusz Kowalczyk wrote: I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include HsIntegerGmp.h ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? What did you do that led up to this point? Erik ./sync-all get sync-all pull ./configure --prefix=/home/shana/ghc-20140308 make I also ran ‘./sync-all reset --hard’ I now ran ‘make clean ./configure --prefix=/home/shana/ghc-20140308 make’ and saved the results. You can find the log at http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB). -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory
On 08/03/14 08:11, Mateusz Kowalczyk wrote: On 08/03/14 07:19, Erik de Castro Lopo wrote: Mateusz Kowalczyk wrote: I'm trying to build HEAD but I'm getting libraries/integer-gmp/cbits/gmp-wrappers.cmm:30:26: fatal error: HsIntegerGmp.h: No such file or directory #include HsIntegerGmp.h ^ compilation terminated. make[1]: *** [libraries/integer-gmp/dist-install/build/.depend-v-dyn.c_asm] Error 1 make: *** [all] Error 2 This in on 32-bit Gentoo Linux, using 7.6.3 to build. I've been able to build fine before. My last few versions are … drwxr-xr-x5 shana shana 4096 Feb 19 04:45 ghc-20140218 drwxr-xr-x5 shana shana 4096 Feb 22 22:04 ghc-20140220 drwxr-xr-x5 shana shana 4096 Feb 25 08:44 ghc-20140225 which means that the problem must have been introduced some time after that point. Does anyone have any ideas? What did you do that led up to this point? Erik ./sync-all get sync-all pull ./configure --prefix=/home/shana/ghc-20140308 make I also ran ‘./sync-all reset --hard’ I now ran ‘make clean ./configure --prefix=/home/shana/ghc-20140308 make’ and saved the results. You can find the log at http://fuuzetsu.co.uk/misc/ghc-20140308-gmp-log (~1.8MB). I was told in #ghc that I need to re-run ‘perl boot’ as well. I'll try it and post back if it still fails. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Optimized Cmm containing useless blocks
While looking at some generated Cmm I saw things like this c1Cm: goto c1Cq; c1Cq: i.e. useless basic blocks that haven't been optimized away. Is this to be expected? -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Optimized Cmm containing useless blocks
On a related note, doesn't Cmm support fall-through branches? Heap checks use two branches instead of one branch and one fall-through case: c1Cq: Hp = Hp + 152; if (Hp I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; c1Cs: I64[BaseReg + 904] = 152; goto c1Cp; c1Cp: R1 = PicBaseReg + a_r1za_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c1Cr: On Sat, Mar 8, 2014 at 9:21 AM, Johan Tibell johan.tib...@gmail.com wrote: While looking at some generated Cmm I saw things like this c1Cm: goto c1Cq; c1Cq: i.e. useless basic blocks that haven't been optimized away. Is this to be expected? -- Johan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC for performance testing
On 08/03/14 07:54, Herbert Valerio Riedel wrote: Hi Simon, On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote: On 06/03/14 09:50, Johan Tibell wrote: [...] * Are there any tweaks to mk/build.mk http://build.mk we can do to make the build faster without compromising the results? Turn down the stage2 optimisation, and turn off the docs: GhcStage2HcOpts = -O ...but doesn't that compromise the compile-time metrics collected by nofib about GHC's performance? I think Johan is interested primarily in runtime performance, but yes if you care about compile time then it's better to leave GhcStage2HcOpts at the default. Cheers, Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Building GHC for performance testing
one idea that I think Ben Gamari (or was it Reid?) pointed out is that another (potentially valuable) metric is how long does it take for ghc to build itself On Sat, Mar 8, 2014 at 5:20 AM, Simon Marlow marlo...@gmail.com wrote: On 08/03/14 07:54, Herbert Valerio Riedel wrote: Hi Simon, On 2014-03-08 at 08:18:20 +0100, Simon Marlow wrote: On 06/03/14 09:50, Johan Tibell wrote: [...] * Are there any tweaks to mk/build.mk http://build.mk we can do to make the build faster without compromising the results? Turn down the stage2 optimisation, and turn off the docs: GhcStage2HcOpts = -O ...but doesn't that compromise the compile-time metrics collected by nofib about GHC's performance? I think Johan is interested primarily in runtime performance, but yes if you care about compile time then it's better to leave GhcStage2HcOpts at the default. Cheers, Simon ___ 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: Optimized Cmm containing useless blocks
Seems like something that should be delegated to a peep hole optimizer. What you describe make it possible to reorder the basic blocks at a later stage. Alexander On Mar 8, 2014 9:24 AM, Johan Tibell johan.tib...@gmail.com wrote: On a related note, doesn't Cmm support fall-through branches? Heap checks use two branches instead of one branch and one fall-through case: c1Cq: Hp = Hp + 152; if (Hp I64[BaseReg + 856]) goto c1Cs; else goto c1Cr; c1Cs: I64[BaseReg + 904] = 152; goto c1Cp; c1Cp: R1 = PicBaseReg + a_r1za_closure; call (I64[BaseReg - 8])(R1) args: 8, res: 0, upd: 8; c1Cr: On Sat, Mar 8, 2014 at 9:21 AM, Johan Tibell johan.tib...@gmail.comwrote: While looking at some generated Cmm I saw things like this c1Cm: goto c1Cq; c1Cq: i.e. useless basic blocks that haven't been optimized away. Is this to be expected? -- Johan ___ 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
