Per some investigation and discussion at the hackathon, I've looked in to refactoring the register allocator. IMCC keeps track of all symbolic registers within a compilation unit in a hash of SymReg structures.
When building PBC, IMCC needs to decide how to map symbolic registers ($P1, $N0, $S3, lexicals, etc) to Parrot registers (P0, N0, S0, etc). To do so, it performs several types of analysis -- much of this is non trivial anyway -- but ends up walking this hash several times per compilation unit per register type. Algorithmically speaking, even though coloring and allocating registers is non-trivial, I believe even a mathemetician would refer to this as sort of a disaster. The more I dive into IMCC's allocation and context flow and optimization code, the more I realize that refactoring it into something more amenable to how PIR and PBC actually work will take a lot of time that perhaps I could spend on implementing new things, not just improving existing things that (for all that they're proofs of concept with bugs, sure, but known bugs) mostly work. Much of the problem is that plenty of things are interconnected unfortunately. That means that changing something in one place ripples throughout the code. I'm starting to convince myself that the entire PBC-modeling structure that IMCC takes is fundamentally wrong -- but the only likely replacement, pirc, has blocked for months awaiting better access to PBC. We can probably reach Parrot 1.0 without replacing IMCC (and that's probably the right decision), but IMCC as it exists now will be an increasing maintenance and performance and evolutionary drawback over time. Fortunately, we can implement stage one of refactoring by cleaning up the code slightly and performing small changes -- but we really need to rethink its internal data structures dramatically. That makes me wonder if we're better off investing resources elsewhere and encouraging a likely replacement. -- c
