This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Trying to make list nodes smaller, but the C++ FE keeps beating me down
- From: Mike Stump <mrs at apple dot com>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 15 May 2005 13:25:03 -0700
- Subject: Re: [PATCH]: Trying to make list nodes smaller, but the C++ FE keeps beating me down
On Sunday, May 15, 2005, at 11:44 AM, Daniel Berlin wrote:
Stop here.
:-)
We have other trees that don't have types :)
Yes, and our take is that we should just move to hard typing for all of
them, and escape the confines of soft tree typing for them all.
The problem is, if you can pass it to a (tree t) function, and they
check TREE__TYPE (t), then we wind up in limbo. Even with the checking
code to make it soft, it is hard to be sure that you got everything.
Hard typing is harder, but, easier to statically check, say, by
compiling it.
We can't easily, because it's in CALL_EXPR, and a *lot* of places
expect all operands of a call expr to be a tree
I didn't say hard typing would be trivial. It is a lot of typing
(ouch, sorry for the unexpected pun), but at least you can be sure that
when it compiles, it is probably complete and right.
I suppose this type of patch would take us one step closer to hard
typing, if someone else wanted to do that, so I like the general
direction...
As for fixing the bugs that show up in C++, hard proposition, but no
harder than hard typing. :-) To be able to add TREE_LIST_WT, one
would need to audit/understand all the uses of TREE_LIST in the C++ FE
and the backend, and then fix them up as appropriate.
Also, to see the savings, you may need to add more sizes to the
allocation routine's pool sizes, otherwise, it will just truncate up to
the next bigger size, which can undo all the savings one would
otherwise see.