On 3/19/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
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
Unfortunately, this patch doesn't bootstrap for me on i686-pc-linux-gnu:
/home/dgregor/Projects/mainlinegcc-build/./prev-gcc/xgcc
-B/home/dgregor/Projects/mainlinegcc-build/./prev-gcc/
-B/home/dgregor/Projects/mainlinegcc-install/i686-pc-linux-gnu/bin/
-I../../mainlinegcc/libcpp -I. -I../../mainlinegcc/libcpp/../include
-I../../mainlinegcc/libcpp/include -O2 -g -fomit-frame-pointer -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic
-Wno-long-long -Werror -I../../mainlinegcc/libcpp -I.
-I../../mainlinegcc/libcpp/../include
-I../../mainlinegcc/libcpp/include -c -o expr.o -MT expr.o -MMD -MP
-MF .deps/expr.Po ../../mainlinegcc/libcpp/expr.c
../../mainlinegcc/libcpp/expr.c: In function '_cpp_parse_expr':
../../mainlinegcc/libcpp/expr.c:701: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
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.
I strongly agree. Subcodes look like they'll either end up being
complicated (e.g., what I did with TYPEOF_TYPE as a subcode), slow
(the LANG_TREE_CODE option puts a branch into the equivalent of
TREE_CODE), or both.
Cheers,
Doug
