[ In private mail, Jeff re-discovered the tree-eh compilation time
issues with unusual test cases such as eh/cleanup1.C. I replied
that I thought that the only viable solution is a data structure
change. ]
I now have a first half-cut at this datastructure change. The
gimplification part was ugly, but managable. The eh part was easy.
The cfg part is monstrous.
In the end I don't think the cfg part is going to be managable
without lowering *all* the other container constructs first.
Doing otherwise would just replace what we have with something
equally baroque.
The good news is that if we *do* lower the other constructs,
then things look to be very clean indeed. Going into the tree
cfg routines we'll have one STATEMENT_LIST containing the entire
function. We'll then proceed to chop it up into smaller lists,
one per block. Blocks will not be connected in any way. When
it comes time to drop to rtl, we can either link them all togther
again, or emit the blocks one at a time, or attempt to preserve
the existing cfg.
For the record, here's the patch I'm playing with. I have all
the tree optimizers disabled, and I'm just making sure that the
gimplifier part works ok. It doesn't quite, yet.
Comments on the data structures and approach welcome.