This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: We're out of tree codes; now what?


On 3/20/07, Mark Mitchell <mark@codesourcery.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]