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]

Re: [RFA:] More compact EH frame info for synchronous EH


On Tue, Apr 12, 2005 at 09:44:49PM +0200, Hans-Peter Nilsson wrote:
> Some numbers for i686-pc-linux-gnu: libstdc++.so .eh_frame size
> shrunk from 57352 to 53500 bytes (93.3%) and the test-program
> .eh_frame from 5340 to 5044 bytes (94.5%).

i386-linux would be a better target, since i686 is
ACCUMULATE_OUTGOING_ARGS, and thus isn't nearly as
affected by this patch.

> *** dwarf2.h	6 Oct 2004 20:27:15 -0000	1.29
> --- dwarf2.h	12 Apr 2005 15:13:02 -0000
> *************** enum dwarf_line_number_x_ops
> *** 669,674 ****
> --- 669,677 ----
>   /* Call frame information.  */
>   enum dwarf_call_frame_info
>     {
> +     /* Use only internally, as a marker.  */
> +     DW_CFA_GNU_BARRIER = -1,

This file is kept in sync with copies in other projects.  I don't see
any need to put this here, rather than a local define in dwarf2out.c.

> +   /* If we'll want compact EH frame tables, annotate call insns so we
> +      can accumulate the info between them.  */
> +   if (CALL_P (insn)
> +       && !after_p
> +       && (flag_unwind_tables || (flag_exceptions && ! USING_SJLJ_EXCEPTIONS))
> +       && !flag_asynchronous_unwind_tables)
> +     {
> +       dw_cfi_ref call_cfi = new_cfi ();
> +       call_cfi->dw_cfi_opc = DW_CFA_GNU_BARRIER;
> + 
> +       /* Don't emit a new label (e.g. by using ""), as that'd get us a
> + 	 new DW_CFA_advance_loc4 that we'd have to eliminate as a
> + 	 special case between two DW_CFA_GNU_BARRIERs.  */
> +       add_fde_cfi (fde_table[fde_table_in_use - 1].dw_fde_current_label,
> + 		   call_cfi);
> +     }

Since you didn't explain how your algorithm works, I'm going to have to
guess.  You're intending to keep data accurate at call sites.  To do 
that, you're adding markers so that you can figure out where those call
sites are?

If synchronous exceptions, you need to check for eh edges, not just 
calls.  (1) Not all calls have exception edges and (2) there are non
call exceptions, and non-call exceptions do not imply
flag_asynchronous_unwind_tables -- we still have known points at 
which exceptions happen.

> + /* See if we can replace the CFI in HEAD with one in TAIL before we hit
> +    a DW_CFA_GNU_BARRIER or the end of the list.  Items in the TAIL chain
> +    can be modified to complete the replacement.  This depends on EH
> +    frame info being output after debug info, else the size of the debug
> +    info will increase.  */

I totally do not understand what you're after here.

> +   /* If we can replace this CFI info with some subsequent info, we're
> +      done with this one.  */
> +   if (for_eh
> +       && !flag_asynchronous_unwind_tables
> +       && cfi_replacement (cfi, cfi->dw_cfi_next))
> +     return;

Ouch.  Now I see the quadraticness.  How do you justify your claim that
these will be small sequences?  Why won't large functions have large
sequences?

Finally, I thought we already had code for !ACCUMULATE_OUTGOING_ARGS
that tracked the cfa and gnu_args_size and emitted them correctly just
before call sites.  Is this optimization supposed to be *only* before
the prologue?  If so, why are calls relevant at all to this discussion;
surely you could do just as well with the NOTE_INSN_FUNCTION_BEG note?



r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]