Re: [patches] Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix

[Jan Hubicka <jh at suse dot cz>]

> Not to great effect.  The stack adjustments for pascal functions eat into
> the current stack frame, whereas deferred pops just accumulate harmlessly.
> I suppose we could omit the adjustment for a single call to a pascal
> function followed by another call to, say, abort, but the potential benefit
> is small.
Sure, I pointed it out just as an example where it may happen.
> > For use in debugger and in unwinding library for x86_64.  For instance the
> > garbage collector needs to unwind stack at any point.
> 
> It does?  Why?  How?  What is this unwinding library of which you speak?
When you have non-conservative garbage collector over multithreaded application.
WHen such beast is activated it needs to parse stacks of all threads and
thus needs to unwind stack at any state of execution.
> > For .eh_frame the current code notices them, remembers and throws away
> > if no call is in the way.
> 
> Yes, that's an example of the optimization I refer to above.
I know.
> 
> >> > Another manifestation of the problem in current tree can be IMO the
> >> > fact that -mno-accumulate-outgoing-args makes gcc to notice pushes and
> >> > emits info to restore global registers, while
> >> > -maccumulate-outgoings-args omits this.
> >> 
> >> I'm sorry, I don't follow.  -maccumulate-outgoing-args doesn't notice
> >> pushes because there shouldn't be any; we should be using the pre-allocated
> >> space.  It does still emit info to restore saved registers, however.
> 
> > Thats the problem - for i386 there are pushes used in prologue/epilogue
> > sequences I need to get noticed.
> 
> But we already notice those pushes, because they have RTX_FRAME_RELATED_P
> set.
Hmm, I see. I am sure it didn't work for me originally (that was the primary
motivation for the patch), I will try to figure out what went wrong.

Honza
> 
> Jason