tree-eh.c vs. CFGs

[Stuart Hastings]

I've been working on the tree-profiling-branch, teaching the inliner to 
work with CFGs.  Since profiling info is hung off CFGs, the inliner 
must work with CFGs in order to do profile-driven inlining.  I have 
this working for C.  The C++ compiler currently fails to build 
libstdc++; the problem seems to be that the inliner doesn't run before 
tree-eh.c anymore.

I'm not a C++ person, so I may have misunderstood something, but it 
appears

1) tree-eh.c currently works on GENERIC parse trees
2) tree-eh.c expects that inlining has been done
3) tree-eh.c makes non-trivial changes to the CFG

In short, both the inliner and tree-eh.c want the other to run first.

I believe the Right Thing to do is revise tree-eh.c to work on CFGs.  I 
can do this, but not quickly; I suspect there are several folks in the 
community that could do this in less time and with fewer bugs than I, 
but you're all probably busy with other stuff.

Assuming I've diagnosed this correctly (I'm very confident that RTH 
will correct any misconceptions I have :-) and tree-eh.c gets revised, 
next I have to deal with the "remove_useless_stmts" pass; it needs a 
similar revision (I have disabled it in my working tree).  After that, 
Java (possibly Ada?).

My point in writing is to a) confirm my diagnosis so I don't waste 
time, and b) solicit help.

Before I embark upon this, um, "exceptional" journey, would anyone else 
like to volunteer?  :-)

stuart hastings
Apple Computer