On Mon, Aug 13, 2007 at 07:05:03PM +0100, Andrew Coppin wrote: > Does GHC do dead code elimination?
Yes - all unused let-binders are removed. > I observe that if you take a module and edit it so that some function is > now no longer exported or called by any exported function, the size of the > *.o file seems to go down. This suggests that dead code within a single > module is eliminated. > > However... how about this? > > module Foo where > > f = ... > g = ... > h = ... > > module Main where > > import Foo > > main = ...f... > > Will the generated executable contain the code for g and h, even though > they aren't called? Or does the unused code get eliminated? How about the > standard libraries? By default, GHC generates one object file per source module, so if any values from that module are used, the entire module is linked in. With the -split-objs flag, GHC generates one object file per top level function, sometimes significantly reducing the size of executables. This is not the default because it puts tremendous strain on the linker. It is common to spend several *minutes* linking base when compiling ghc, and it's not unheard of for ar to simply run out of memory and die. > I read somewhere that if one funtion returns a tuple, and the caller > immediately extracts the values from the tuple, GHC tries to optimise away > the tuple - so it's as if the function can just return multiple values at > once. Is this true? Does it apply only to tuples, or to all types? This is called the Constructed Product Return (CPR) analysis, and it applies to all types with one constructor (in archaic jargon, product types). For instance, (+) (I# x#) (I# y#) = I# (x# +# y#) foo = case 2 + 2 of I# x# -> ... is transformed into: zdzp (I# x#) (I# y#) = (x# +# y#) foo = case 2 + 2 of x# -> ... This is one of the two main pillars of arithmetic unboxing, alongside and equally important to strictness analysis. Stefan
signature.asc
Description: Digital signature
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
