On Mon, Nov 18, 2002 at 04:57:50PM -0000, Simon Marlow wrote:

You should be aware that -split-objs (the trick we use to build our libraries in lots of little bits) gets most of the benefit that you'd get from using -ffunction-sections. You might get slightly more fine-grained discarding of code with -ffunction-sections, but the effect won't be dramatic (I'm guessing). Also there's the issues of telling the garbage collector and the mangler about it. However, it would be nice to be able to use -ffunction-sections/--gc-sections instead of -split-objs. It's been at the back of my mind to have a go at this someday...

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... $T_DOT_WORD = '\.(long|value|byte|zero)'; $T_DOT_GLOBAL = '\.globl'; $T_HDR_literal = "\.section\t\.rodata\n"; # or just use .text??? (WDP 95/11 ) $T_HDR_misc = "\.text\n\t\.align 4\n"; $T_HDR_data = "\.data\n\t\.align 4\n"; # ToDo: change align?? $T_HDR_consist = "\.text\n"; $T_HDR_closure = "\.data\n\t\.align 4\n"; # ToDo: change align? $T_HDR_srt = "\.text\n\t\.align 4\n"; # ToDo: change align? $T_HDR_info = "\.text\n\t\.align 4\n"; # NB: requires padding $T_HDR_entry = "\.text\n"; # no .align so we're right next to _info (argu ably wrong...?) $T_HDR_fast = "\.text\n\t\.align 4\n"; $T_HDR_vector = "\.text\n\t\.align 4\n"; # NB: requires padding $T_HDR_direct = "\.text\n\t\.align 4\n"; $T_create_word = "\t.word"; So basically it's tagging various items directly with the section they go to as it is, so a compiler option may very well be superfluous; just hack ghc-asm. Adding some extra goo in mangle_asm() to get the section name to be related to the symbol doesn't look too bad. -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" ) ) ghc/compiler/main/DriverFlags.hs:250 opt_EnsureSplittableC = lookUp FSLIT("-fglobalise-toplev-names") ./ghc/compiler/codeGen/CgConTbls.lhs:109 genConInfo comp_info data_con = -- Order of things is to reduce forward references mkAbstractCs [if opt_EnsureSplittableC then CSplitMarker else AbsCNop, closure_code, static_code] ./ghc/compiler/codeGen/CodeGen.lhs:260 maybeExternaliseId id | opt_EnsureSplittableC, -- Externalise the name for -split-objs isInternalName name = moduleName `thenFC` \ mod -> returnFC (setIdName id (mkExternalName uniq mod new_occ (nameSrcLoc name))) ./ghc/compiler/codeGen/CodeGen.lhs:276 maybeSplitCode | opt_EnsureSplittableC = CSplitMarker | otherwise = AbsCNop ./ghc/compiler/nativeGen/AbsCStixGen.lhs:272 gencode CSplitMarker | opt_EnsureSplittableC = returnUs (\xs -> StLabel mkSplitMarkerLabel : xs) | otherwise = returnUs id ./ghc/compiler/absCSyn/CLabel.lhs:245 mkSplitMarkerLabel = RtsLabel (Rts_Code "__stg_split_marker") 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/; ... 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 ... 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. Thanks, Bill