24 Feb
2007
24 Feb
'07
4:04 p.m.
On Sat, Feb 24, 2007 at 03:57:31PM -0500, Isaac Dupree wrote: > Stefan O'Rear wrote: > > exec gcc -o yhi -O2 -funit-at-a-time src/runtime/BCKernel/sanity.c > src/runtime/BCKernel/basepath.c [...] depends/ctypes/libffi/src/x86/ffi.c > depends/ctypes/libffi/src/x86/sysv.S > - -lm -lpthread -ldl -lgmp -I. -Idepends/ctypes/libffi/include > - -Idepends/ctypes/libffi/src/x86 -Idepends/ctypes/libffi > - -DVERSION=\"0.7.0-20070224144350-custom\" -DX86 > > A few of those paths passed to the compiler include "x86" (also, -DX86). > Maybe the choice of files (and other compiler flags), in order to > support the FFI on multiple architectures, isn't completely trivial? D'oh. Very good point :) > > IE, less than 6x the time needed to compile a Haskell "hello world" > > with comparable optimization settings. (For those less familiar with > > ghc options, -funit-at-a-time means whole program optimization in this > > context.) We probably don't need separate compilation, let alone > > dependency generation. > > (ghc->gcc) yes :) > yes > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html > "Compiling multiple files at once to a single output file (and using > - -funit-at-a-time) will allow the compiler to use information gained from > all of the files when compiling each of them." > It seems, looking at different versions' manuals, > gcc 4.1 automatically enables -funit-at-a-time with -O or greater > gcc 4.0 automatically enables -funit-at-a-time with -O2 or greater > gcc 3.4 (when the flag was introduced) never automatically enables it. > So the effect of putting the flag there seems to be better optimization > for gcc 3.4 and error for gcc 3.3 and below. Is it worth mentioning the > flag? (Also, is yhi supposed to support C compilers other than "gcc", > which, among other things, probably don't have that flag?) Well, when I last used gcc 3.4 WAS the latest version :) (It is amazing how much I do with haskell now.) Anyway, I was going for "highest set of optimization flags I could remember", ie "slowest C compiler I have". So the fact that it is a gcc-specific option is (hopefully!) irrelevant here. > In any case, you are probably right about that optimization effect when > compiling together multiple files at the same time, that it is a good > effect, assuming it makes the build process less complicated or at least > not more so! Stefab