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]

Re: patch to improve i386 epilogue (version 2)


> I suspect your call counts are still going to be inaccurate -- for
> example flow.c can/will delete calls if they are in an unreachable
> block without calling delete_insn.
> 
> There may be other cases where this can happen too -- we'd really
> need to read all of the optimizers a little more closely.
> 
> Also, don't we have to be careful with the value changing over time?
> 
> ie, what happens if at prologue generation time we think there is a
> call, but due to some optimization after reload we end up deleting
> a call (can this happen?!?) and leaf_function_p returns true.

Currently the i386 epilogue always reloads the stack pointer from
the frame pointer if there is a frame pointer and there are registers
to be reloaded.  All that the patch does is to skip reloading the stack
pointer if it hasn't changed since the prologue.  It's known to be
the same (which implies it doesn't need to be reloaded) if there has
been no function calls and alloca hasn't been used.  It actually isn't
required (though certainly it's desirable) for function_call_count to
be accurate.  It's only required that if function_call_count equals
zero then there must * not * be any function calls.  The worst that
will happen if it is nonzero when it should be zero is that the same
epilogue which is currently being used * all * the time will be used.

The changes which I submitted improve the accuracy of function_call_count
and in some situations improve the i386 epilogue.  I'm not sure I see a
downside. :-)

> Presumably you aren't calling leaf_function_p in the epilogue expander
> because we've already got a sequence started and thus we can't get to
> the original insn chain?

Yep.  I first tried the naive approach of calling leaf_function_p, however
it always returned true. :-(

> Maybe it would be better to pass in a variable to the prologue/epilogue
> expanders indicating whether or not the current function is a leaf
> function.  An interface change for the md files, but a relatively minor
> one.

Maybe.  I'm not sure how much of an advantage that has over simply
continuing to improve the accuracy of function_call_count which is
more efficient then having leaf_function_p scan the function.  Though
I guess that scanning the function looking for calls is simpler then
keeping function_call_count up to date.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------



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