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

["Steven Bosscher" <stevenb dot gcc at gmail dot com>]

On 3/19/07, Doug Gregor <doug.gregor@gmail.com> wrote:
> I went ahead and implemented this, to see what the real impact would
> be. The following patch frees up TREE_LANG_FLAG_5, and uses that extra
> bit for the tree code.
>
> On tramp3d, memory usage remains the same (obviously), and the
> performance results are not as bad as I had imagined:
>
> 8-bit tree code, --enable-checking:
>
> real    1m56.776s
> user    1m54.995s
> sys     0m0.541s
>
> 9-bit tree code, --enable-checking:
>
> real    2m16.095s
> user    2m12.132s
> sys     0m0.562s
>
> 8-bit tree code, --disable-checking:
>
> real    0m55.693s
> user    0m43.734s
> sys     0m0.414s
>
> 9-bit tree code, --disable-checking:
>
> real    0m58.821s
> user    0m46.122s
> sys     0m0.443s
>
> So, about 16% slower with --enable-checking, 5% slower with --disable-checking.

Just because I'm curious and you have a built tree ready...  Does the
patch that Alex sent to gcc-patches the other day help reduce this 5%
penalty?

See the patch here:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01234.html

There are other bitfield optimization related bugs (Roger Sayle should
know more about those) that we can give a higher priority if we decide
to go with the 9 bit tree code field.  IMHO this is still the better
solution than the subcodes idea.

Gr.
Steven