On 3/20/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> On 3/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>>  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.

For that matter, does increasing the tree code limit to 512 codes
instead of 256 actually put off the day of reckoning enough to be worth it?

I think so. It took us, what, 10 years to go through 256 codes? Even
if we accelerate the pace of development significantly, we'll still
get a few years out of 512 codes. All the while, we should be hunting
to eliminate more of the "common" bits in tree_base (moving them into
more specific substructures, like decl_common), allowing the tree code
to increase in size. When we hit that 16-bit tree code, we'll get a
small bump in performance when all of the masking logic just
disappears. 16 bits is my goal, 9 bits is today's fix.

 Cheers,
 Doug

Reply via email to