Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure if it's O(n^2) or O(2^n) headaches, but definitely issues. At the moment I've got parrot churning on some pir code and it's taking quite a while. Final time tally:
real 41m46.978s user 21m24.300s sys 0m41.080s
Ack.
I expected this would happen. Most probably it is register-coloring/spilling.
I'm a little rusty on the register colorer; I do know the first version I wrote
was not very fast for large numbers of registers, but I believe Leo had improved
on it a bit.
I'd really like to see the piece of code so I can do some profiling.
Ended with a missing symbol error, of course, just to rub it in a bit. vm_stat reports a lot of zero-fill page allocation (about 1600 4K pages/sec) though the memory footprint isn't growing to match, so that might indicate at least something of the problem. (For all I know there's some sort of degenerate GC issue somewhere, depending on how imcc does its memory allocation and management)
That could be IMCC repeatedly allocating/freeing its interference graphs for each basic block, but I'm not positive.
I know IMCC's being redone, and we're nowhere near close to optimized, but I think it'd be worth it to get a handle on what sorts of things are likely to trigger off exponential time compiles when fed to IMCC. I'm assuming that it's due to a combination of sub size (about 61K of source in one sub) and locals needing coloring (132) but it'd be nice to know for sure.
There are several tests I can think of that we should include in IMCC.
1) A large number of locals with a very long code segment, without branches or labels. This would tests large graph coloring without lots of basic blocks.
2) A large number of locals _with_ the normal amount of branches and labels. This would test the life analysis on a large number of basic blocks.
3) A small number of locals with variants of 1 & 2 above for branching/labels.
Any chance of getting the code sample?
-Melvin
