This is the mail archive of the
mailing list for the GCC project.
Re: We're out of tree codes; now what?
On 3/13/07, Mike Stump <email@example.com> wrote:
On Mar 13, 2007, at 5:29 AM, Doug Gregor wrote:
> I don't know if we'll be able to get rid of *enough* tree codes,
> without going to some kind of two-level hierarchy.
I think we can. I have a patch, that in theory should work (doesn't
bootsrap yet, not sure why). I use subcodes for all the Objective-C
We would get a lot of tree codes back if we could subcode the C++
_TYPE nodes effectively. I look forward to seeing your patch.
> Some upcoming bits that will need more tree codes:
> - C++0x (my guess: > 10 new tree codes),
If we decide to subcode, we're going to have to have reject patches
that add any new codes without removing codes on a one for one basis.
That's fine, so long as we give good guidance to submitters stating
how to subcode.
I'm imagining a whole economy built on the swapping of tree codes for
various other commodities :)
> If trees were only used by the middle end, or only used by the
> C/C++/Objective C/C++ front ends, we'd be okay. But we decided to use
> them in both places.
Actually, if we keep the front-end data structures away from the mid-
end and/or back-end, we can use the same values in the codes between
the front-end and the rest of the compiler. This would potentially
give us back many codes, without the _cost_ of subcodes. The
downside, printers (debug_tree) of codes would have to be away from
which realm the code came from to print it.
It would also become harder to debug problems that stem from failing
to lower a particular construct for the middle end. Still, it would be
a big win.
Doug "Hey man, wanna buy a tree code?" Gregor