[Yhc] yhc build bug?
Stefan O'Rear
stefanor at cox.net
Sat Feb 24 16:04:06 EST 2007
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
More information about the Yhc
mailing list