object code blow up by optimization

[Christian Maeder]

Simon Peyton-Jones wrote:
> 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.

Thanks, for looking into it. For our code bloat, related to the 
ShATermConvertible instances, there are no associative operations. I've 
included the basic class and a few instances that pose no problem until 
very late in our final big binary (with many more instances).

Currently, I simply set "-fvia-C -O0" in parts of our code and hope that 
-optc-O1 helps a bit.

Cheers Christian

P.S. I've changed infixl to infixr
infixr 6 <>
infixr 6 <+>
infixr 5 $$, $+$

Not much difference in code size but a bit faster compared to the 
numbers I've posted before:

http://hackage.haskell.org/trac/ghc/ticket/490

Linking ...

real    7m37.899s
user    6m45.562s
sys     0m11.161s

maeder at turing:~/haskell/examples> ll a.out HasCASL/PrintLe.o
-rwxr-xr-x  1 maeder wimi 6468124 2006-01-26 19:48 a.out
-rw-r--r--  1 maeder wimi 2010772 2006-01-26 19:46 HasCASL/PrintLe.o

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AbstractSyntax.hs
Type: text/x-haskell
Size: 4570 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20060126/956ec18a/AbstractSyntax.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Conversion.hs
Type: text/x-haskell
Size: 4798 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20060126/956ec18a/Conversion.bin