This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: We're out of tree codes; now what?

On 3/13/07, Mike Stump <> 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
TYPE nodes.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]