On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
As for the current problem, I think a 3% hit is pretty big. I didn't find subcodes that ugly, so I guess I'm inclined to go with subcodes, and avoid the hit.
We know that one still mostly unaddressed problem that tree-ssa left us with, is poorer code for bitfield operations. That means the 3% can probably be reduced further. Another thing I like about the 9-bit tree code approach is that we keep the size of the 'tree' data structure the same, so there is no effect on memory. I think that 3% is unfortunate but worth it because the impact on the structure of the compiler is negligible, while subcodes require significant rewrites of some parts of gcc. Let's be fair here: A 3% hit is small compared to the cumulative slowdown we already have in GCC 4.3 since the start of stage 1, and negligible compared to the total slowdown we've accumulated over the years. I know this is not really an argument, but let's face it: Much larger patches and branch merges have unintentionally increased compile time by more than 3%, and we didn't have a large discussion about it. Those were the power plants, and Doug's patch is the.... (you've guessed it!) bikeshed! ;-) Back to the technical arguments... Subcodes require a bigger 'tree' data structure so there will be a memory usage hit, I don't think there's disagreement about that. We don't know if subcodes will have no compiler speed hit. At least, I don't recall seeing any numbers yet. But if 'tree' is bigger, the chances are that we'll see poorer cache behavior, and therefore a slower compiler. So the subcodes approach may end up no better than the 9-bit tree code approach wrt. compiler speed. (Of course, for a good technical decision, you'd have to try both approaches and do a fair comparison.) I also think subcudes are bug prone, because you have more cases to handle and people are unfamiliar with this new structure. The impact of subcodes on the existing code bases is just too large for my taste.
I think it's fair for front ends to pay for their largesse. There are also relatively cheap changes in the C++ front end to salvage a few codes, and postpone the day of reckoning.
I think that day of reckoning will come very soon again, with more C++0x work, more autovect work, OpenMP 3.0, and the tuples and LTO projects, etc., all requiring more tree codes. And if there comes a point somewhen, where we can go back to a smaller tree code field, it is much easier to do so with the 9-bit tree code approach, than with subcodes. Gr. Steven
