The new register allocator chains all of the iCodes together earlier than the old register allocator. As a result, a few functions that expect one chain per eBBlock end up processing iCodes beyond the end of the intended eBBlock. Thus iCodes in block j are actually processed j+1 times instead of just once. This problem occurs with RegFix(), createRegMask(), and dumpEbbsToFileExt(). For dumpEbbsToFileExt(), it's just a cosmetic problem. For the others, it's at least an inefficiency and might lead to a subtle bug. My inclination is that since the regression tests have been passing, this is just a benign problem, but it wouldn't hurt for someone else to take a second look at what this does to the first two functions.
For RegFix() I am sure this is just a slight efficiency issue: It ignores most variabels inclusing those that are spilt. All the variables it treats are spilt, thus applying it multiple times to the same iCode doesn't change it's behaviour: The second time it sees an icode all variables it ignored previously will still be ignored for the same reason and the previously reated ones are spilt now and thus ignored.
Philipp
Since we don't know if this causes a real problem, I'm reducing the priority.
Philipp