first stab at -ffunction-sections

[Simon Marlow]

> 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=20
> through ghc5, whatever debian's latest shipping version is):
>=20
> ghc/compiler/main/DriverFlags.hs:250
>   ,  ( "split-objs"     , NoArg (if can_split
>                                     then do writeIORef=20
> v_Split_object_files True
>                                             add v_Opt_C=20
> "-fglobalise-toplev-name
> s"
>                                     else hPutStrLn stderr
>                                             "warning: don't=20
> know how to  split \
>                                             \object files on=20
> 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=20
> one per arch):
>=20
>     # strip the marker
>=20
>     $str =3D~ s/(\.text\n\t\.align=20
> .(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\
> n/$1/;
>     $str =3D~ s/(\t\.align=20
> .(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\n/$1/; =20
>=20
>    ...

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=20
> within the
> compiler except for whatever might circumvent ghc-asm, if anything.
>=20
> 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:
>=20
> 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:
>=20
> 0805b140 T __stginit_PosixDB
>=20
> 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