I noticed a lot of not-obviously-used stuff brought in from various
libraries and wanted to nuke some of the unneeded things. Step 1 was
trying to compile the libraries with the option, which didn't quite
fly... it looks like ghc-asm is the primary sufferer, and I'm not sure
the compiler option is needed...
Yes, indeed you could do this in ghc-asm. But don't forget the native
code generator too...
-split-objs I didn't really realize was there. I see (tracing
through ghc5, whatever debian's latest shipping version is):
ghc/compiler/main/DriverFlags.hs:250
, ( split-objs , NoArg (if can_split
then do writeIORef
v_Split_object_files True
add v_Opt_C
-fglobalise-toplev-name
s
else hPutStrLn stderr
warning: don't
know how to split \
\object files on
this architecture
) )
-split-objs has to go to some trouble to make more symbols global so
that they can still be resolved after the assembler file has been split
into chunks. This is one rather ugly hack that it would be nice to get
rid of.
Then in ghc/driver/split/ghc-split.lprl:287 (there's actually
one per arch):
# strip the marker
$str =~ s/(\.text\n\t\.align
.(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\
n/$1/;
$str =~ s/(\t\.align
.(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\n/$1/;
...
Yes, this is all particularly horrible too. The splitter has to go to
some trouble to make sure that local constants (strings and the like)
get duplicated in each assembler chunk that refers to them, subverting
the commoning up of constants that gcc does.
So to me it looks feasible to figure out who's fooling with these
things, though it's probably not necessary to do any of this
within the
compiler except for whatever might circumvent ghc-asm, if anything.
At any rate, I am finding the amount of unused code/data linked into
the generated executables significant... for instance, in a non-
concurrent program:
080a1c64 D MVar_modifyMVarzu_closure
0805aeb8 T MVar_modifyMVarzu_entry
0805aece T MVar_modifyMVarzu_fast3
0805aeb8 T MVar_modifyMVarzu_info
The IO library requires MVars (it's thread-safe) so most programs will
have some MVar bits linked in. I'm not sure why modifyMVar in
particular is being included though.
... and as it's a 9-line script to mangle patches, it's certainly not
using this:
0805b140 T __stginit_PosixDB
The idea with -ffunction-sections or brewing up an equivalent is to
build the libraries with it so when the final executable is linked, it
imports only the code and statically-allocated data it uses from them.
Ok, I'm convinced :) Let us know if you need any more help.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
