exception handling poll

[Richard Henderson <rth at cygnus dot com>]

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~