On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> 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
