RE: object code blow up by optimization

Just to let you know, I can reproduce this problem nicely (thank you for
setting up the repro case).  It turns out to be caused by the
simplifier's inlining policy which goes if not exponential then
something very like it.  It's made dramatically worse by the fact that
$$ and <+> are left-associative.  If you change them to right-assoc the
problem disappears I think.

That's not an excuse -- the simplifier should not do this -- but it
might be a useful workaround.

Simon

| -----Original Message-----
| From: Christian Maeder [mailto:maeder@xxxxxx]
| Sent: 10 January 2006 17:57
| To: Simon Peyton-Jones; glasgow-haskell-bugs@xxxxxxxxxxx
| Subject: Re: object code blow up by optimization
| 
| Hi,
| 
| we generate a couple of source files with orphaned instances for the
| classes Typeable and ShATermConvertible.
| 
| Only adding {-# OPTIONS -O0 #-} made my code bloat problem go away
(for
| the time being).
| 
| Avoiding some class methods (with mere default definitions) made the
| object code (and .hc files) only blow up half as much.
| 
| -fno-strictness also kept many object files small until one module
(that
| imported all the instances) really exploded.
| 
| I give up now on this matter.
| 
| Cheers Christian
| 
| 
| Christian Maeder wrote:
| > Christian Maeder wrote:
| >>>> I've a few files that produce ten times bigger .o files when
| >>>> compiled with optimization (-O). This blow-up prevents linking on
a
| >>>> mac.
| >>
| >> I had some success by adding
| >>
| >> {-# OPTIONS -fno-strictness #-}
| >
| > This option did finally not help.
| >
| > The code bloat may have something to do with unfolding (or other
| > optimizations) within method instances.
| >
| > We have about 400 data types with (partly overlapping) Typeable and
| > ShATermConvertible instances. I now changed a member function with a
| > default definition to a global function and the binaries became
smaller.
| >
| > I could not investigate the problem any further, yet.
| >
| > Cheers Christian