Stefan O'Rear wrote:
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.
Not related to optimisation, but... is there some switch to warn you if
something gets removed? (Presumably this means you forgot to export
something, or you haven't coded the bit that calls it yet or something.)
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.
Right, OK. I had a feeling that was the case.
(I once compiled a program that used the GHC API. The final binary was
several times larger than ghc.exe...)
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.
Ouch! o_O
Probably simpler for me, as a human, to split the program into a
sensible module structure... ;-)
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).
Right. So it doesn't have to have strict fields or anything? Just has to
have exactly one constructor?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
