Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix

[Jason Merrill <jason at redhat dot com>]

>>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:

>> In message <20010102200705.H6101@atrey.karlin.mff.cuni.cz>you write:
>> > Hi
>> > The final.c assumes that ACCUMULATE_OUTGOING_ARGS hosts never modify
>> > stack pointer in the function body.  This is not quite true for i386
>> > that may call pascal functions and modify stack pointer in few
>> > other cases as well.

>> Under precisely what conditions can code still modify the stack pointer
>> when ACCUMULATE_OUTGOING_ARGS is true?  And I'm curious why calling pascal
>> routines requires modification of the stack pointer.

> 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.

> 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.

Jason