This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: We're out of tree codes; now what?
On Mon, 12 Mar 2007, Mike Stump wrote:
> :-) I don't have any objections, as long as people can keep the compilation
> speed up, though, sounds like a bit of work. I'd look towards a project
> architect to help steer us towards goodness and keep us out of trouble. I can
> see some advantage to having a cleaner boundary between the front-ends and the
> mid-end.
You won't get a very clean separation, given that back ends manipulate C
and C++ structures for target-specific built-in functions (including
overloaded ones), attributes, pragmas, etc., that layout information is
needed in the front ends, and that debug info involves target-specific and
languages-specific information. You can improve things, but the
(language, target, debug format) combinations will always be there with
the associated need for one part of the compiler to know about structures
from others.
If you want separation, I suggest starting by making one thing at a time
that shouldn't be a tree cease to be a tree everywhere. Partial work on
TREE_LIST elimination is on the LTO branch. The CALL_EXPR parts have been
merged, work on merging the TYPE_ARG_TYPES parts is in progress, there are
many smaller patches there not yet merged and many other TREE_LIST cases
not yet eliminated. Where those cases are front-end-specific structures,
they can become front-end-local types. Another case that shouldn't be
trees is identifiers. Key here is that each incremental stage should
reduce memory usage and be useful on its own.
--
Joseph S. Myers
joseph@codesourcery.com