[Haskell-cafe] GHC optimisations

[Andrew Coppin]

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?