This is the mail archive of the
mailing list for the GCC project.
Re: [patches] Re: dwarf2/ACCUMULATE_OUTGOING_ARGS fix
> 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.
> >> > 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
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.