From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: egcs@cygnus.com Subject: exception handling poll Date: Thu, 16 Oct 1997 08:31:00 -0000 Message-id: <19971016005725.09113@dot.cygnus.com> X-SW-Source: 1997-10/msg00645.html A little poll for those that have been complaining about exception handling frame unwind info being included for C: Assuming the .eh_frame section is completely read-only, at what eh/text ratio would you find it acceptible that that information is always there? Can you live with 10%? 8? 5? 3? ---------------------------- I was having a look at a "random" nice large program this evening, f771, and trying to work out how big the frame info would be assuming ideal generation. Some basic numbers: 1533276 bytes text, 4210 functions. The dwarf2 frame info requires 16 bytes/function static overhead for eh info length, cie address, function address, and function length. For f771, that brings us up to a few more than 67k, or 4.4% even before adding any actual information. Depending on how the initial_information insn bits in the CIE is interpreted, this could potentially encode all the information for all x86 with 3 CIEs. Which means about 60 more bytes. It would seem then, that somewhere around 4.5% is the best we could possibly do on f771 with dwarf2 frame info. (I suppose some more large program data points would be good. Anyone have x86 glibc handy compiled with eh info?) Now, with the current adv4/cfa_ofs/adv4/cfa_reg sequence on x86 to set up the frame pointer, this eats up another 60204 bytes, 43366 of which is in the adv4's. Assuming we knew we could reduce these to adv, we'd reduce that 43k to 8673 for a total of 25511. Relaxing rigour for a moment, changing to def_cfa would total 12630. Adding these to our base totals, we get 6.0% and 5.2% respectively. Recording one saved register is adv/ofs for 1+2 bytes; recording two or three (there are only 3 saved regs not including bp), takes 4. Add this in to our running total and we get 6.04% min and 7.16% max. This 7.2% number is interesting because I think it is about as good as can theoretically be done without linker help; assistance from within the assembler doesn't help. What would be required to get here is exact length attributes on the insns in the i386.md file. With an inexact but bounding length attribute, we could minimize the current lossage above this number from 4*3 to 1*3 bytes/FDE. This would make for about 8.0% on the running total. So. Given the number I posted last night at 12.5%, a patch I put together this evening that yields about 11% on x86, a rock-bottom minimum somewhere between 4.5 and 6% (depending on other constraints) and the fact that the sparc port is already down at 5.4%: Is it worth spending the effort required to get that last 5%, possibly by requiring a new version of gnu ld? Or would I just be wasting my time since the overhead would still be considered unacceptible? r~