Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix

[Jan Hubicka <jh at suse dot cz>]

> 
> > Simply because the i386 "pascal" convention makes function to deallocate the
> > stack after return.  This needs to be handled with -maccumulate-outgoing-args
> > by adjusting stack back after the return.
> 
> Why does this need to happen for EH unwinding?  If we're returning via
> exception, we won't have run the epilogue which would have deallocated the
> stack.  The args_size stuff is there to handle caller-pop semantics.

You've missed what I am saying.  The sequence is

pascal function call changing stack pointer
..
<some code>
..
lazy update of stack back to original value
<some branch>

If exception happends in <some code>, the information about stack offset is
bogus.  This is rare case, but can actually happen.
> 
> > Later the stack adjustments may be moved further into code, so they cause
> > failures in the tests explicitly constructed for this case.
> 
> > But the real motivation for this patch was different - I was investigating
> > possibility of using dwarf2 unwind info as the only way to unwind stack on
> > x86_64 (by dropping the i386 base pointer) and I needed to measure how large
> > code bloat it causes to emit explicit unwind info for each instruction.
> 
> > Enabling -maccumulate-outgoing-args caused important improvements, since gcc
> > dropped updating the CFA offsets in the epilogues, that still do use pop
> > instruction.
> 
> Yes.  For an arbitrary testcase, I see that -fomit-frame-pointer causes the
> unwind info to explode, and adding -maccumulate-outgoing-args brings it
> back under control.
This is still true after the patch, since the code pointed out above is really,
really rare. The benefits are just slightly lower.

Honza
> 
> Jason