This is the mail archive of the gcc-patches@gcc.gnu.org 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] |
[ 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. r~
Attachment:
d-sl-1.gz
Description: GNU Zip compressed data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |