whole program optimization

2007-12-23 Thread Isaac Dupree 
GHC optimizes less effectively when parts of a program are in different 
modules, or are exported from a module.  Therefore, merging all the code 
into one module Main (main) would help.  Unfortunately, Haskell source 
syntax is ill-suited to this; for example:


module-boundary monomorphism restriction
different defaults in different modules
deriving (Show, Read) --for renaming everything that's
  -- in different modules, so it doesn't conflict
new GHC {..} etc. record stuff
imports as, unknown import lists

Also, program correctness can be wrongly increased; for example, using 
instances that were defined in some module imported by Main, but not by 
the module that uses the instance.  I suppose this might affect 
overlapping instances somehow?


But it seems plausible to merge modules on the GHC Core level, after 
desugaring and type-checking.  Then the one infelicity would be that 
orphan RULES could apply in more places (RULES are converted and applied 
to Core!).  Is this a problem?  Does it already happen when modules 
import small inlinings from .hi files of modules that don't have access 
to the RULES?


It would not actually be quite whole-program as long as all the 
libraries are compiled separately and only available through their .o 
and incomplete .hi files.  Which is okay; but it would be nice if they 
could all also be compiled to the complete-.hi that we thought might 
serve for External Core -- and then one would just need to tell GHC to 
take all those complete-.hi's and compile them together into one 
executable.  (except for complications like C _stub files, etc, etc. 
Also some parts of `base` might be wired-in enough that they need some 
thought before messing with them.)  Then _any_ function that was only 
used once would be inlined, and GHC would generally be free to make 
decisions like that (at the GHC-speed price of having to look at all 
program and library code in detail) (however the GHC interface to this 
works, Cabal could probably help automate it somehow?)


(Unfortunately, ghc-haskell source syntax doesn't provide an easy way to 
encode Core, even if we wanted to convert it back into GHC-compilable 
Haskell, without unsafeCoerce everywhere, I think?)


So it's more complicated than it seems on the surface, but it could be 
done; I only wonder how effective it would be on various programs.  I 
assume GHC doesn't currently implement any optimizations that can _only_ 
be whole-program, so it would still not be quite like Jhc, though this 
basic support might allow some such optimizations to be implemented.


Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: whole program optimization

2007-12-23 Thread Neil Mitchell 
Hi Isaac,

I've had similar thoughts before. Once GHC can read and write external
Core this should become a half hour hack. I did a similar thing in
Yhc, and it really is trivial
(http://darcs.haskell.org/yhc/src/compiler98/Core/Linker.hs). I'm sure
there would be a few corner cases, but those kind of things can easily
be patched over.

I think there would be speed improvements, but not as dramatic as for
something that was designed to do whole-program from the outset.

Thanks

Neil - who really wants external Core


On 12/23/07, Isaac Dupree [EMAIL PROTECTED] wrote:
 GHC optimizes less effectively when parts of a program are in different
 modules, or are exported from a module.  Therefore, merging all the code
 into one module Main (main) would help.  Unfortunately, Haskell source
 syntax is ill-suited to this; for example:

 module-boundary monomorphism restriction
 different defaults in different modules
 deriving (Show, Read) --for renaming everything that's
-- in different modules, so it doesn't conflict
 new GHC {..} etc. record stuff
 imports as, unknown import lists

 Also, program correctness can be wrongly increased; for example, using
 instances that were defined in some module imported by Main, but not by
 the module that uses the instance.  I suppose this might affect
 overlapping instances somehow?

 But it seems plausible to merge modules on the GHC Core level, after
 desugaring and type-checking.  Then the one infelicity would be that
 orphan RULES could apply in more places (RULES are converted and applied
 to Core!).  Is this a problem?  Does it already happen when modules
 import small inlinings from .hi files of modules that don't have access
 to the RULES?

 It would not actually be quite whole-program as long as all the
 libraries are compiled separately and only available through their .o
 and incomplete .hi files.  Which is okay; but it would be nice if they
 could all also be compiled to the complete-.hi that we thought might
 serve for External Core -- and then one would just need to tell GHC to
 take all those complete-.hi's and compile them together into one
 executable.  (except for complications like C _stub files, etc, etc.
 Also some parts of `base` might be wired-in enough that they need some
 thought before messing with them.)  Then _any_ function that was only
 used once would be inlined, and GHC would generally be free to make
 decisions like that (at the GHC-speed price of having to look at all
 program and library code in detail) (however the GHC interface to this
 works, Cabal could probably help automate it somehow?)

 (Unfortunately, ghc-haskell source syntax doesn't provide an easy way to
 encode Core, even if we wanted to convert it back into GHC-compilable
 Haskell, without unsafeCoerce everywhere, I think?)

 So it's more complicated than it seems on the surface, but it could be
 done; I only wonder how effective it would be on various programs.  I
 assume GHC doesn't currently implement any optimizations that can _only_
 be whole-program, so it would still not be quite like Jhc, though this
 basic support might allow some such optimizations to be implemented.

 Isaac
 ___
 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: ANNOUNCE: GHC version 6.8.2

2007-12-23 Thread Ian Lynagh 
On Tue, Dec 18, 2007 at 12:08:50PM +1100, Manuel M T Chakravarty wrote:
 I wrote,
 Ian Lynagh wrote:
  =
   The (Interactive) Glasgow Haskell Compiler -- version 6.8.2
  =
 
 A binary distribution for Mac OS X 10.5 (Leopard) is available from
 
  http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2
 
 I just updated the binary distribution at
 
   http://www.cse.unsw.edu.au/~chak/haskell/ghc-6.8.2-i386-apple-darwin.tar.bz2
 
 Ian, can you please update the binary on the download page?

Done!


Thanks
Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: binary-dists for ghc-6.8.2

2007-12-23 Thread Ian Lynagh 
On Tue, Dec 18, 2007 at 08:44:23PM +0100, Christian Maeder wrote:
 
 I've built binary distributions

Thanks! All added to the download page.


Ian

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.8.2

2007-12-23 Thread alpheccar 

Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ?
I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- 
all-packages -split-objs -i -idist/build/autogen -idist/build -i. - 
Idist/build -Iinclude -#include HsBase.h -odir dist/build -hidir  
dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - 
package-name base -XCPP -idist/build  -H16m -O -O -Rghc-timing - 
fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ 
Twins.o  -ohi dist/build/Data/Generics/Twins.hi

ghc-6.8.2: panic! (the 'impossible' happened)
  (GHC version 6.8.2 for powerpc-apple-darwin):
lookupVers1 base:GHC.Prim sym{tc}

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

ghc: 49130112 bytes, 8 GCs, 2017280/398 avg/max bytes residency  
(2 samples), 17M in use, 0.01 INIT (0.05 elapsed), 1.01 MUT (2.52  
elapsed), 0.30 GC (3.20 elapsed) :ghc

make[2]: *** [dist/build/Data/Generics/Twins.o] Error 1
make[1]: *** [make.library.base] Error 2
make: *** [stage1] Error 2

Thanks,
Christophe.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-i naked flag

2007-12-23 Thread Alex Jacobson 
The current docs use -i without any arguments to reset the path back to 
[].  That is an interesting feature but it is much less useful than 
being able to use shell based tab completion when entering command line 
options.  I suggest that the -i reset feature be removed in favor of 
e.g. --clear-search-path


-Alex-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

--make should not touch the -o file if it doesn't change it

2007-12-23 Thread Alex Jacobson 
Right now, if you recompile with --make, the exeutable gets a new 
timestamp.  That seems incorrect.  Is this a bug?


-Alex-
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: whole program optimization

2007-12-23 Thread Stefan O'Rear 
On Sun, Dec 23, 2007 at 07:35:20AM -0500, Isaac Dupree wrote:
 GHC optimizes less effectively when parts of a program are in different 
 modules, or are exported from a module.  Therefore, merging all the code 
 into one module Main (main) would help.  Unfortunately, Haskell source 
 syntax is ill-suited to this; for example:
...
 So it's more complicated than it seems on the surface, but it could be 
 done; I only wonder how effective it would be on various programs.  I 
 assume GHC doesn't currently implement any optimizations that can _only_ be 
 whole-program, so it would still not be quite like Jhc, though this basic 
 support might allow some such optimizations to be implemented.

It's been done.  http://www.cs.utah.edu/~hal/HAllInOne/index.html

Stefan


signature.asc
Description: Digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: -i naked flag

2007-12-23 Thread Seth Kurtzberg 
On Sun, 23 Dec 2007 11:36:50 -0500
Alex Jacobson [EMAIL PROTECTED] wrote:

 The current docs use -i without any arguments to reset the path back to 
 [].  That is an interesting feature but it is much less useful than 
 being able to use shell based tab completion when entering command line 
 options.  I suggest that the -i reset feature be removed in favor of 
 e.g. --clear-search-path

zsh completion is configurable in such a way that you can work around this 
issue, but in general I don't disagree.

 
 -Alex-
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
 


-- 
Seth Kurtzberg [EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 6.8.2

2007-12-23 Thread Gregory Wright 


Hi Christophe,

On Dec 23, 2007, at 11:02 AM, alpheccar wrote:


Was someone able to build ghc 6.8.2 on PPC with OS X 10.4 (Tiger) ?
I had no problems to build the 6.8.1 but with 6.8.2, I get the error:

I was able to build 6.8.2 three times on PPC/Tiger (10.4.11) without  
error
using 6.6.1 as a boostrap compiler.  What are you using to compile  
6.8.2?


../../compiler/stage1/ghc-inplace -package-name base-3.0.1.0 -hide- 
all-packages -split-objs -i -idist/build/autogen -idist/build -i. - 
Idist/build -Iinclude -#include HsBase.h -odir dist/build -hidir  
dist/build -stubdir dist/build -package rts-1.0 -O -fglasgow-exts - 
package-name base -XCPP -idist/build  -H16m -O -O -Rghc-timing - 
fgenerics -c Data/Generics/Twins.hs -o dist/build/Data/Generics/ 
Twins.o  -ohi dist/build/Data/Generics/Twins.hi

ghc-6.8.2: panic! (the 'impossible' happened)
 (GHC version 6.8.2 for powerpc-apple-darwin):
   lookupVers1 base:GHC.Prim sym{tc}

Please report this as a GHC bug:  http://www.haskell.org/ghc/ 
reportabug




Best Wishes,
Greg

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADT pattern match in non-rigid context

2007-12-23 Thread Isaac Dupree 

Neil Mitchell wrote:

Hi Simon,


You should be giving a type signature to rewrap!  That should fix it.


Thanks, all works fine now :-)


it would be great if the error message suggested giving a type signature 
as a solution (or maybe it already does, in the HEAD?)


Isaac



Neil


| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
| Neil Mitchell
| Sent: 17 December 2007 16:23
| To: glasgow-haskell-users@haskell.org
| Subject: GADT pattern match in non-rigid context
|
| Hi,
|
| Upgrading from GHC 6.6 to 6.8 has caused some code to stop working:
|
| --
| {-# OPTIONS_GHC -fglasgow-exts #-}
|
| module Data2 where
|
| data CCompany
|
| data Paradise :: * - * where
| CC :: Paradise CCompany
|
| rewrapCC CC = []
| --
|
| [1 of 1] Compiling Data2( Data2.hs, interpreted )
|
| Data2.hs:12:9:
| GADT pattern match in non-rigid context for `CC'
|   Tell GHC HQ if you'd like this to unify the context
| In the pattern: CC
| In the definition of `rewrapCC': rewrapCC CC = []
|
| This code is from the Uniplate benchmarking code, which runs the
| Paradise benchmark from SYB on Uniplate, Compos and SYB. The Compos
| code uses GADT's, so the program first needs to convert from standard
| data structures to GADT's before it can work, then back at the end.
| It's the problem of converting from a GADT to a normal data structure
| that is failing.
|
| So is there an easy workaround? Or should I be asking GHC HQ to unify things?
|
| Thanks
|
| Neil
| ___
| 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



___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users