It's not an infinite loop, but it keeps contracting the same procedure more than once. If you rip out all the tests under "shiver's tests" the problem goes away. Put some of them back, it takes longer. Put more back, it takes even longer etc.

It's not the macro either. Looks like the cond is causing the problem. Looks like an O(n2) behavior with n being the number of branches in the cond.

Note the double occurrance of the folded expression, which is probably a result of the fact that the procedure k31 that's generated by cond's expansion is contracted twice. Add a line and you get three entries for the newly added line:

Multiple contractions of the same function is already incorrect ("contraction" means inlining of a function called once). I think the real problem are nested contractions. In the last example above, k46 is nested in k37. The former gets contracted, then the latter (in the same optimization pass). In this case it seems to happens repeatedly. For inlining this case (an inlined procedure being the target of additional inlining) is taken care of by having the inline-target db entry - we probably need this (or something similar) for contraction, too.

In other words, do you think the bug is in the parts of the optimizer that handle contractions rather than perform-pre-optimization!?

I do, yes. There is a check for the inline-target db entry, which is done for procedures where inlining takes place. I think this must also be done for contractions, but I have to try it out first (real soon).