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)


> Inaccuracies in the computation need to be thought through since they
> can lead to incorrect code. 

Agreed.

> I believe the only cases where we can get incorrect code due to an
> inaccuracy are due to the call count being too small.  If the count
> is too high, then we merely generate less efficient code (though
> that's potentially a serious issue too).

Correct.  Note that currently function_call_count is inaccurate and we
are always generating less efficient code in the ix86 epilogue.

> So, are we sure we are counting all the generate calls?  What if
> GCSE needs to insert multiple calls in various threads of a function
> to make a particular call globally redundant?

I was unable to see what you're referring to after taking a quick peek
at GCSE.  Could you say more about this and where in GCSE it can happen?

> What about passes after initial rtl generation which call named
> expanders which may create libcalls (sh for example), or which
> may generate a libcall for for common operations like mult, div,
> sign/zero extension, etc (mn10x ports) via optabs?
>
> I think we have the potential to lose in both situations, and by
> missing the generation of calls, we could end up generating incorrect
> code.

I was assuming that all function calls which defer adjusting the
stack are initially created by expand_call and that they are only
duplicated by copy_rtx_and_substitute.  Gcc doesn't currently
keep track of other internally generated function calls in
function_call_count.

> I'm starting to lean this way too (scanning for calls once in a while
> instead of trying to keep accurate counts).  I suspect there's too
> many places where you'll have to go find code which emits calls and
> deletes calls.

If we're not interested in improving the accuracy of function_call_count,
then perhaps the existing code which maintains it should be removed from
gcc so that the naive (i.e. me) don't attempt to use it.

What about the notion of having a global flag called current_function_is_leaf
which is set by scanning for calls prior to local_alloc?  There are
situations in which it's useful to known that the function is a leaf.

BTW, I would prefer to ignore calls which in the prologue for the purpose
loading the PIC register when testing for a leaf function.

> Thinking this through a little, it also occurs to me that you might
> just be able to look at whether or not the stack pointer is live at
> entry to the last basic block.
> 
> In fact, that might be the best solution.  The nice thing is it keeps
> flow.c and the epilogue code in sync (which is very important from a
> correctness standpoint).

I can look at this, however I believe that it is still useful to know
if the function is a leaf.  For example, Intel recommends always omitting
the frame pointer for leaf functions.  One approach is to clear
frame_pointer_needed if the function is a leaf.

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